Визуальное тестирование приложений Electron: веб в десктопной оболочке, баги в придачу

Ключевые моменты

Electron рендерит веб-контент внутри десктопной оболочки, что означает: Ваше приложение наследует все визуальные баги веба — плюс специфические десктопные
Изменяемые размеры окон, нативные меню, поддержка нескольких мониторов и различия рендеринга между ОС создают категории визуальных багов, отсутствующие в обычном вебе
Тестировать Electron-приложение как простой сайт — ошибка: десктопный контекст фундаментально меняет визуальный опыт
Автоматизированное визуальное тестирование — единственный жизнеспособный подход для покрытия комбинаторики ОС × разрешение × DPI × размер окна

Electron определяется в своей официальной документации как «фреймворк для создания нативных десктопных приложений с веб-технологиями (HTML, CSS, JavaScript), сочетающий Chromium для рендеринга и Node.js для доступа к системным функциям в едином кроссплатформенном runtime» (Electron Documentation, electronjs.org).

За этим элегантным определением скрывается реальность, знакомая каждому разработчику Electron: Вы получаете лучшее от веба (экосистема, продуктивность, богатые UI-компоненты) и худшее от веба (несогласованность CSS, проблемы рендеринга, переменная производительность). И ко всему этому добавляется дополнительный уровень сложности, связанный с десктопным окружением.

Если Вы разрабатываете Electron-приложение — а, скорее всего, Вы используете несколько (VS Code, Slack, Discord, Figma, Notion, Obsidian) — эта статья покажет, почему визуальное тестирование Вашего десктопного приложения заслуживает особого внимания и почему подход «как веб» недостаточен, хотя и остаётся правильной отправной точкой.

Electron наследует все визуальные проблемы веба

CSS остаётся CSS

Ваше Electron-приложение использует тот же движок рендеринга, что и Chrome (Chromium, через проект Electron, который поставляет специфичную версию Chromium). Это означает, что все визуальные проблемы веба применимы: регрессии CSS после обновления зависимостей, переполнение текста, проблемы z-index, неправильно масштабированные изображения, дёрганые анимации, шрифты, которые не загружаются.

Если Вы уже занимались визуальным тестированием для веба, эти проблемы Вам знакомы. И они в точности так же присутствуют в Electron.

Но вот ловушка: многие команды, разрабатывающие Electron-приложения, пришли не из веба. Они пришли из нативной десктопной разработки (C++, C#, Java Swing), где проблем рендеринга CSS не существует. Они сталкиваются с этими проблемами впервые, без опыта и инструментов для их решения.

Обновления Chromium: тихий риск

Каждое мажорное обновление Electron включает новую версию Chromium. И каждая новая версия Chromium может незаметно изменить рендеринг. Модификация субпиксельного антиалиасинга, изменение в расчётах округления, эволюция в обработке шрифтов — эти изменения редко документируются как breaking changes, но могут вызвать измеримые визуальные регрессии.

Команда Electron выпускает новую мажорную версию примерно каждые восемь недель. Согласно официальному блогу Electron, каждый мажорный релиз интегрирует версию Chromium, версию Node.js и версию V8. Это много потенциальной поверхности изменений.

Если Вы не запускаете визуальные тесты до и после каждого обновления Electron, Вы принимаете тихий риск регрессии по всему интерфейсу.

Десктопная специфика, которая меняет всё

Изменяемое окно: responsive на стероидах

В вебе «responsive design» означает адаптацию layout к нескольким предопределённым breakpoints (мобильный, планшет, десктоп). Возможные viewports многочисленны, но ограничены существующими размерами экранов.

На десктопе окно Вашего Electron-приложения может принять буквально любой размер, от 400×300 пикселей до 3840×2160, проходя через все промежуточные размеры. Пользователи могут менять размер свободно, и они это делают.

Это создаёт непрерывный спектр возможных layout, а не дискретный набор breakpoints. Ваше приложение должно быть визуально корректным при любом размере — а промежуточные размеры (между Вашими breakpoints) часто именно то место, где появляются проблемы.

Типичные сценарии багов изменения размеров включают:

Sidebar, перекрывающий основной контент, когда окно слишком узкое, чтобы отображать оба, но слишком широкое, чтобы запустить «свёрнутый» режим.

Таблица, выходящая за свой контейнер и создающая неожиданный горизонтальный скролл при определённой ширине.

Кнопки действий в header, перекрывающиеся, когда горизонтального пространства недостаточно, но мобильный breakpoint ещё не достигнут.

Плавающая панель (инспектор, терминал, command palette), уходящая за границы экрана, когда окно слишком маленькое.

Нативные меню: интерфейс, который Вы не контролируете

Electron-приложения могут использовать нативные меню ОС (menu bar в macOS, оконное меню в Windows и Linux). Эти меню рендерятся операционной системой, а не Вашим CSS-кодом. Их внешний вид варьируется в зависимости от ОС, версии ОС и системной темы пользователя.

Визуально зона перехода между нативным меню и Вашим веб-контентом — частый источник проблем. На macOS title bar и меню управляются системой. На Windows многие Electron-приложения используют кастомную title bar (frameless window с воссозданными в CSS кнопками управления) для более современного вида.

Эта кастомная title bar — визуально критический компонент. Кнопки закрытия, минимизации и максимизации должны быть в правильном месте, правильного размера, правильного цвета и корректно вести себя при наведении. И всё это варьируется между платформами: на macOS кнопки слева и круглые; на Windows — справа и квадратные; на Linux — зависит от оконного менеджера.

Если Ваше приложение использует кастомную title bar, визуальное тестирование должно покрывать её на каждой целевой ОС. Это компонент, который пользователи видят и используют постоянно, и визуальный баг здесь немедленно заметен.

Мульти-мониторность и переменный DPI

Современное десктопное окружение часто означает ноутбук с Retina-дисплеем (2x DPI), подключённый к внешнему монитору 1080p (1x DPI). Пользователи перемещают Ваше приложение с одного экрана на другой. И когда приложение перемещается с экрана 2x на 1x, всё должно перерендериться корректно.

Связанные с DPI визуальные проблемы особенно коварны:

Bitmap-изображения (PNG, JPG), спроектированные под единый DPI, выглядят размыто на экранах высокого разрешения или пикселизированно на низкоразрешённых. Иконки и иллюстрации должны поставляться в нескольких разрешениях или в векторном формате (SVG).

Однопиксельные границы отображаются по-разному в 1x и 2x. На экране 2x CSS-граница в 1 пиксель составляет 0,5 физического пикселя, что может сделать её невидимой или несогласованной в зависимости от движка рендеринга.

Тени, градиенты и эффекты blur тонко меняют рендеринг между разрешениями. То, что является лёгким размытием на экране 1x, становится выраженным размытием на экране 2x, или наоборот.

Текст подвергается разному антиалиасингу. Читаемость тонкого шрифта может быть отличной в 2x и плохой в 1x. Типографический выбор, работающий на экране Вашей разработки (вероятно, MacBook Retina), может быть катастрофическим на внешнем мониторе Вашего пользователя.

Панель задач, dock и system tray

Ваше приложение взаимодействует с десктопным окружением через иконку панели задач (Windows/Linux), dock (macOS) и system tray. Эти крошечные иконки (от 16×16 до 48×48 пикселей) должны быть безупречны. Бейджи уведомлений, статус-оверлеи, контекстные меню — это визуальные элементы, которые Ваши пользователи видят постоянно, даже когда Ваше приложение не на переднем плане.

Три ОС: три рендеринга, три набора проблем

macOS: требовательный эталон

macOS часто является основной платформой разработки. Визуальные особенности включают кнопки светофора (красную, жёлтую, зелёную) слева, рендеринг шрифтов Core Text (визуально «жирнее» при том же весе по сравнению с Windows) и нативную обработку тёмного режима, которая должна гармонировать с темой Вашего приложения.

Windows: разнообразие конфигураций

Windows предлагает наибольшее разнообразие конфигураций. Разрешения варьируются от 1366×768 (всё ещё 20% экранов согласно StatCounter в 2025) до 3840×2160. Факторы масштабирования (от 100% до 200%) добавляют сложность, отсутствующую на macOS.

Рендеринг шрифтов DirectWrite производит заметно отличные результаты от Core Text: тоньше, чётче, иногда менее читаемо в малых размерах. Режим доступности «Высокая контрастность» может кардинально изменить внешний вид Вашего приложения, если Ваши CSS-стили его не поддерживают.

Linux: особый случай

Фрагментация десктопных окружений (GNOME, KDE, XFCE) затрудняет нормализацию. Но согласно Stack Overflow Developer Survey 2024 около 27% разработчиков используют Linux. Если Ваше приложение нацелено на разработчиков, Linux заслуживает покрытия. Минимально жизнеспособный вариант: Ubuntu с GNOME.

Стратегия визуального тестирования для Electron

Определите матрицу тестирования

Первый шаг — явно определить комбинации, которые Вы будете тестировать. Минимально Ваша матрица должна включать:

Целевые ОС. macOS (последняя и предыдущая версии), Windows 10, Windows 11. Linux Ubuntu LTS, если Ваша аудитория это оправдывает.

Приоритетные разрешения экрана. Для каждой ОС два или три самых используемых Вашими пользователями разрешения. На macOS: 1440×900 и 2560×1600 (Retina). На Windows: 1920×1080 и 1366×768. Адаптируйте на основе Ваших реальных аналитических данных.

Факторы DPI. Минимум 1x и 2x. На Windows добавьте 1,5x (150%), что является очень распространённой настройкой.

Размеры окон. Полный экран, половина экрана (split screen) и уменьшенный «минимальный функциональный» размер. Эти три размера покрывают реальные сценарии использования.

Автоматизация захвата на нескольких ОС

Главный технический вызов визуального тестирования Electron — захват скриншотов на нескольких ОС. У Вас есть несколько вариантов.

Подход мультиплатформенного CI. GitHub Actions, GitLab CI и Azure Pipelines поддерживают jobs на macOS, Windows и Linux. Настройте job визуального тестирования на каждую ОС, который запускает Ваше приложение, переходит к экранам для тестирования и захватывает скриншоты.

Подход Playwright. Playwright нативно поддерживает автоматизацию Electron с версии 1.20: запуск приложения, взаимодействия, захват скриншотов, всё кроссплатформенно.

Подход Delta-QA. Для команд, которые не хотят поддерживать скрипты, Delta-QA предлагает no-code подход для захвата и визуального сравнения экранов Вашего приложения.

Приоритетные зоны для мониторинга

В Electron-приложении некоторые области более склонны к визуальным регрессиям, чем другие. Сфокусируйте свои визуальные тесты на этих зонах:

Title bar и элементы управления окном. Если Вы используете кастомную title bar (frameless window), тестируйте её на каждой ОС. Кнопки закрытия/минимизации/максимизации, область перетаскивания, заголовок приложения — всё должно быть pixel-perfect и соответствовать конвенциям платформы.

Изменяемые панели. Если Ваше приложение имеет панели (sidebar, нижняя панель, инспектор), которые пользователи могут изменять в размере, тестируйте рендеринг при разных размерах панели. Resize handles, минимальные и максимальные размеры, адаптирующийся контент — всё должно быть визуально корректным.

Контекстные меню. Нативные контекстные меню рендерятся по-разному на каждой ОС. Кастомные контекстные меню (в CSS) должны быть протестированы на позиционирование (без выхода за границы окна), читаемость и согласованность с темой приложения.

Модальные окна и диалоги. Системные диалоги (открыть файл, сохранить, печать) являются нативными и не требуют визуального тестирования с Вашей стороны. Но кастомные модальные окна Вашего приложения должны быть протестированы, особенно их центрирование, оверлей и поведение, когда окно маленькое.

Состояния загрузки и переходы. Запуск Electron-приложения может занять несколько секунд. То, что пользователь видит за это время (splash screen, экран загрузки, пустое окно), является частью опыта и заслуживает визуального тестирования.

Самые частые ошибки

Тестирование только на одной ОС

Это самая распространённая и самая дорогостоящая ошибка. Если Ваша команда разрабатывает на macOS и тестирует на macOS, визуальные баги, специфичные для Windows и Linux, доходят до продакшна без фильтрации. А Windows обычно представляет большинство Вашей пользовательской базы Electron (согласно данным Electron Fiddle и многих популярных Electron-приложений, Windows часто составляет от 60 до 70% установок).

Игнорирование факторов DPI

Тестировать только в 1x, когда значительная доля Ваших пользователей в 2x (или наоборот), — рецепт сюрпризов. Проблемы DPI тонкие — слегка размытый текст, исчезнувшие границы, пикселизированные иконки — но они дают впечатление недоработки, которое подрывает доверие.

Отношение к Electron как к веб-браузеру

Ваше Electron-приложение — не вкладка браузера. Это десктопное приложение, которое пользователь установил, у которого есть собственное место в панели задач и которое судят по стандартам нативных приложений. Пользователи терпят сайт со слегка сломанным layout. Они не терпят установленное десктопное приложение с очевидными визуальными проблемами.

Пренебрежение промежуточными размерами окон

Если Вы тестируете только в полноэкранном режиме, Вы пропускаете все баги, появляющиеся, когда пользователь запускает Ваше приложение в режиме половины экрана (split screen с другим приложением). Это чрезвычайно распространённое использование на десктопе, особенно для инструментов продуктивности.

FAQ

Electron использует Chromium, значит обычных веб-тестов достаточно, верно?

Нет. Electron использует Chromium для рендеринга, это правда. Но среда принципиально иная: бесконечно изменяемые окна, отсутствие адресной строки, нативные меню ОС, интеграция с панелью задач, поддержка нескольких мониторов, переменный DPI. Ваши обычные веб-тесты покрывают рендеринг Chromium в браузере. Они не покрывают специфику десктопного окружения Electron. Оба уровня необходимы.

Как обрабатывать различия рендеринга шрифтов между macOS и Windows?

Рендеринг шрифтов структурно различается между Core Text (macOS) и DirectWrite (Windows). Единственный надёжный способ обработать эти различия — поддерживать отдельные визуальные эталоны для каждой ОС. Не сравнивайте скриншот macOS со скриншотом Windows — они всегда будут различны, и эти различия нормальны. Сравнивайте macOS с macOS, Windows с Windows.

Нужно ли тестировать каждое обновление версии Electron?

Да, и это не обсуждается. Каждое мажорное обновление Electron включает новую версию Chromium, способную изменить рендеринг. Лучшая практика — запускать Ваш полный набор визуальных тестов до и после обновления, сравнивать результаты и валидировать различия. Некоторые различия будут улучшениями движка рендеринга (которые Вы можете принять, обновив эталоны), другие будут регрессиями (которые Вы должны исправить или сообщить).

Как тестировать режим высокой контрастности Windows?

Windows High Contrast Mode — это настройка доступности, заменяющая цвета Вашего приложения схемой с высокой контрастностью. Вы можете включить её программно в Вашем CI-окружении тестов (через системные настройки или инструменты автоматизации). Захватывайте скриншоты в этом режиме и поддерживайте отдельный эталон. Это особенно важно, если Ваше приложение нацелено на профессиональные среды, где политики доступности строги.

Моё Electron-приложение нацелено только на macOS. Нужно ли тестирование на нескольких ОС?

Если Ваше приложение действительно поддерживает только одну ОС, тестирование на нескольких ОС, очевидно, не нужно. Но проверьте это предположение: многие приложения «только macOS» обнаруживают, что часть их пользователей запускает приложение на Windows через неофициальные установки или корпоративные запросы. Если Вы рассматриваете будущую поддержку Windows, инвестирование в тестирование на нескольких ОС сейчас значительно облегчит переход.

Какова идеальная частота визуального тестирования для Electron-приложения?

При каждом коммите, затрагивающем интерфейс, и при каждом обновлении версии Electron или UI-зависимостей. На практике интегрируйте визуальное тестирование в Ваш CI/CD pipeline, чтобы оно запускалось автоматически на каждом pull request. Стоимость случайного ложного срабатывания бесконечно ниже стоимости визуальной регрессии, отгруженной тысячам десктопных пользователей.

Для углубления

Electron даёт Вам силу создавать десктопные приложения с веб-технологиями. Это суперсила. Но эта суперсила несёт ответственность: визуальные баги веба следуют за Вами на десктоп, и к ним присоединяется когорта проблем, специфичных для нативного окружения.

Хорошая новость: если Вы уже умеете визуально тестировать веб, у Вас есть 80% необходимых навыков. Оставшиеся 20% — мульти-ОС матрица, факторы DPI, изменяемые окна, нативные меню — естественное расширение Вашего существующего подхода.

Electron наследует все проблемы веба. Тестируйте его как веб, а затем идите дальше.

Попробовать Delta-QA бесплатно →