Cypress Visual Testing: Полное руководство по добавлению визуального тестирования
Визуальное тестирование (или visual testing) — это метод автоматизированной проверки, который сравнивает скриншоты веб-интерфейса с эталонными изображениями для обнаружения любой графической регрессии — сдвинутая кнопка, изменённый шрифт, элемент, перекрывающий другой.
Cypress — замечательный инструмент. Мы ценим его за скорость, интуитивный API, огромное сообщество. Но давайте будем честны с самого начала: Cypress не выполняет визуальное тестирование нативно. В отличие от Playwright, который включает toHaveScreenshot() из коробки, Cypress заставляет вас использовать сторонние плагины для любого сравнения скриншотов.
И это более серьёзная проблема, чем кажется.
Это руководство рассматривает существующие подходы к добавлению визуального тестирования в Cypress, их реальные ограничения и почему радикально иной подход заслуживает вашего внимания.
Почему в Cypress нет встроенного визуального тестирования
Это вопрос, который никто не задаёт достаточно громко. Playwright это сделал. Почему не Cypress?
Официальный ответ дипломатичен: Cypress сосредоточен на функциональном тестировании. Честный ответ более нюансирован. Визуальное тестирование — это сложная проблема — управление базовыми изображениями, допуск различий в рендеринге, сглаживание, анимации — и Cypress решил предоставить это экосистеме плагинов.
Результат? Фрагментация. Каждый плагин делает всё по-своему, со своими соглашениями, своими багами и своими рисками заброшенности. Вы не выбираете одно официально поддерживаемое решение. Вы делаете ставку на open source проект, поддерживаемый горсткой участников — или на платный облачный сервис.
Для команд, которые построили всю свою тестовую инфраструктуру на Cypress, это реальная дилемма. Мигрировать на Playwright только ради визуального тестирования нереально. Добавлять хрупкий плагин тоже не вариант. Давайте посмотрим, что есть.
Подход 1: cypress-image-snapshot
Самый известный плагин в экосистеме. Он опирается на jest-image-snapshot (который в свою очередь использует pixelmatch) для попиксельного сравнения скриншотов.
Как это работает
Установка требует нескольких манипуляций с конфигурацией Cypress — ничего непреодолимого, но достаточно файлов для редактирования, чтобы ошибка легко прокралась. Если хотите точные команды, попросите вашего любимого ИИ-ассистента сгенерировать конфигурацию — ему это нравится, и это не даст ему скучать между хайку о машинном обучении.
После настройки принцип прост: вы добавляете пользовательскую команду в тесты, которая делает скриншот и сравнивает его с эталонным изображением в репозитории. Первый запуск создаёт базовую линию. Последующие обнаруживают отклонения.
Ограничения, о которых вам не говорят
Проблема поддержки. Этот плагин переживал длительные периоды бездействия. Когда будете читать эти строки, проверьте дату последнего коммита на GitHub. Если прошло больше шести месяцев — задайте себе вопросы.
Ложные срабатывания. Попиксельное сравнение безжалостно. Немного другой рендеринг шрифта между вашей машиной и CI? Ложное срабатывание. Сглаживание, которое зависит от GPU? Ложное срабатывание. Вы тратите больше времени на настройку порогов допуска, чем на написание тестов.
Нет интерфейса для ревью. Когда тест падает, вы получаете diff-изображение в папке. Нет дашборда, нет рабочего процесса утверждения. Вы открываете изображение в файловом менеджере и щуритесь, пытаясь найти разницу. Это кустарный подход.
Управление базовыми изображениями в Git. Сотни PNG-файлов в репозитории. Конфликты слияния бинарных файлов — это кошмар. История Git раздувается. Некоторые команды в итоге используют Git LFS, добавляя ещё один уровень сложности.
Подход 2: Percy (BrowserStack)
Percy — это облачный сервис визуального тестирования, который интегрируется с Cypress через SDK. Подход принципиально другой: вместо локального сравнения Percy отправляет DOM и ресурсы на свои серверы, рендерит страницу в реальных браузерах и сравнивает результаты в веб-дашборде.
Как это работает
Вы устанавливаете SDK Percy для Cypress, добавляете вызов в тесты для создания снэпшота, и Percy делает остальное в облаке. Рабочий процесс ревью происходит в веб-интерфейсе Percy: вы видите различия, утверждаете или отклоняете.
Для точной конфигурации ваш настольный ИИ выдаст сниппет за три секунды — это его звёздный час, дайте ему блеснуть вместо копирования из документации, которая устареет через полгода.
Ограничения
Стоимость. Percy — платный сервис. Бесплатный план есть, но ограничен количеством снэпшотов в месяц. Для команды, которая тестирует серьёзно, расходы растут быстро. Мы не будем здесь детализировать тарифы — они регулярно меняются — но ожидайте существенную статью бюджета.
Облачная зависимость. Ваши снэпшоты рендерятся на серверах Percy. Если сервис упал — ваши тесты не проходят. Если BrowserStack (который купил Percy) решит изменить тарифы или условия — у вас нет рычагов.
Задержка в CI. Отправить DOM внешнему сервису, подождать рендеринг, получить результат — это добавляет время к вашему пайплайну. Не критично на десяти тестах, но на пятистах — ощутимо.
Привязка к поставщику. Как только все ваши базовые изображения в Percy, переезд куда-то ещё означает воссоздание всего с нуля. Это классическая ловушка проприетарных облачных сервисов.
Подход 3: Happo
Happo — менее известная альтернатива Percy, с похожим позиционированием: облачный сервис, который делает и сравнивает скриншоты ваших компонентов.
Интеграция с Cypress существует, но она менее зрелая, чем у Percy. Продукт надёжный, команда серьёзная, но пользовательская база меньше. Меньше документации от сообщества, меньше ответов на Stack Overflow, меньше отзывов.
Те же проблемы стоимости и облачной зависимости применимы.
Подход 4: Applitools Eyes
Applitools продвигает концепцию дальше с технологией сравнения на основе ИИ (их "Visual AI"). Вместо попиксельного сравнения алгоритм пытается обнаружить «визуально значимые» различия, игнорируя незначительные вариации рендеринга.
На бумаге это привлекательно. На практике продукт мощный, но сложный. Настройка нетривиальна, ценообразование непрозрачное, а зависимость от проприетарного сервиса полная. Для подробного анализа ознакомьтесь с нашей карточкой Applitools.
Корневая проблема: визуальное тестирование как дополнение
Все эти подходы имеют общий структурный недостаток: они рассматривают визуальное тестирование как дополнение к функциональному.
У вас есть набор тестов Cypress. Вы прививаете к нему плагин или SDK. Добавляете вызовы в существующие тесты. Визуальное тестирование становится паразитом функционального — зависимым от той же инфраструктуры, тех же селекторов, того же кода.
Когда Cypress выпускает мажорное обновление, ваш плагин визуального тестирования ломается. Когда функциональный тест меняет маршрут, ваша визуальная базовая линия устаревает. Когда разработчик изменяет селектор, падает И функциональный, И визуальный тест.
Это хрупкая модель по своей природе.
Визуальное тестирование заслуживает быть полноценным участником, а не безбилетником в функциональном наборе. Оно отвечает на другой вопрос («правильно ли это выглядит?» vs «работает ли это?») и должно иметь собственные инструменты, собственные рабочие процессы, собственные базовые изображения.
Что ваши тесты Cypress не видят
Тест Cypress проверяет, что кнопка существует и запускает правильное действие. Он не проверяет, что кнопка видима, правильно выровнена, правильного цвета, с правильными отступами, на всех разрешениях экрана.
Визуальные баги коварны, потому что проходят все функциональные тесты. Форма работает идеально — но метка накладывается на поле ввода на мобильном. Выпадающее меню открывается корректно — но появляется за другим элементом. Отображаемая цена верна — но валюта отображается белым на белом фоне.
Эти баги попадают в продакшен, потому что их никто систематически не ищет. И они дорого обходятся: в доверии, в конверсиях, в тикетах поддержки. Чтобы понять, что визуальное тестирование действительно обнаруживает, конкретные примеры часто красноречивее теории.
Альтернатива: отделить визуальное тестирование от кода
А что если визуальному тестированию вообще не нужен Cypress?
Это позиция, которую мы отстаиваем в Delta-QA, и мы полностью её принимаем. Визуальному тестированию не нужен код. Не нужны плагины. Не нужны CSS-селекторы и конфигурация webpack.
Delta-QA работает иначе. Вы перемещаетесь по сайту, записываете маршрут через point-and-click, и инструмент делает эталонные скриншоты. При каждом следующем запуске он сравнивает и показывает различия в специализированном интерфейсе. Без кода. Без плагинов. Без зависимости от Cypress, Playwright или чего-либо ещё.
Это не компромисс. Это другая философия. Функциональное тестирование и визуальное тестирование — это две разные дисциплины, каждая из которых заслуживает собственных инструментов. Ваш набор тестов Cypress продолжает проверять, что всё работает. Delta-QA проверяет, что всё выглядит правильно. Они дополняют друг друга, не мешая.
Для QA-команд, которые не программируют, — это освобождение. Для разработчиков — экономия времени. Для всех — меньше ложных срабатываний и рабочий процесс ревью, который имеет смысл. Узнайте, почему визуальное тестирование без кода меняет правила игры.
FAQ
Может ли Cypress выполнять визуальное тестирование без плагина?
Нет. Cypress может делать скриншоты с помощью cy.screenshot(), но не предлагает никакого встроенного механизма сравнения. Вы получаете изображения, но сравнение с базовыми, управление порогами допуска и рабочий процесс утверждения нужно добавлять через плагин или внешний сервис.
Какой лучший плагин Cypress для визуального тестирования?
Универсального ответа нет. cypress-image-snapshot — самый популярный в open source, но страдает от проблем с поддержкой и ложных срабатываний. Percy предлагает лучший пользовательский опыт, но это платный сервис. «Лучший» зависит от вашего бюджета, терпимости к ложным срабатываниям и готовности поддерживать дополнительный код.
Percy бесплатный с Cypress?
Percy предлагает бесплатный план с ограниченным количеством ежемесячных снэпшотов. Для серьёзного профессионального использования понадобится платный план. Тарифы регулярно меняются — проверяйте актуальные условия на их сайте.
Можно ли делать визуальное тестирование Cypress в CI/CD?
Да, все описанные подходы работают в CI/CD. Но именно там проблемы множатся: различия рендеринга между средами, управление базовыми изображениями, время выполнения. CI усиливает каждую хрупкость вашей конфигурации визуального тестирования.
Почему просто не использовать Playwright для визуального тестирования?
Если вы начинаете новый проект, Playwright с его встроенным toHaveScreenshot() — действительно лучший выбор для визуального тестирования на основе кода. Но если у вас уже есть значительный набор тестов Cypress, миграция нереальна. И даже с Playwright вы остаётесь в парадигме визуального тестирования через код, с его ограничениями в поддержке и доступности.
Может ли Delta-QA заменить тесты Cypress?
Нет, и это не цель. Cypress отлично справляется с функциональным тестированием: проверка работы взаимодействий, корректных ответов API, соблюдения бизнес-логики. Delta-QA сосредоточен на визуальном тестировании: проверке того, что интерфейс выглядит правильно. Эти два инструмента дополняют друг друга, а не конкурируют.
Сколько времени нужно для настройки визуального тестирования в Cypress?
С cypress-image-snapshot рассчитывайте на один-два часа для установки и базовой настройки, затем несколько дней на калибровку порогов допуска и стабилизацию тестов от ложных срабатываний. С Percy техническая настройка быстрее, но организационная часть (управление снэпшотами, рабочий процесс ревью, интеграция CI) требует времени. С Delta-QA первый визуальный тест работает за считанные минуты.
Заключение
Cypress — отличный инструмент функционального тестирования. Мы его используем, рекомендуем за то, что он делает хорошо. Но делать вид, что он удовлетворительно справляется с визуальным тестированием — это самообман.
Плагины существуют. Они работают, более или менее. Но они хрупкие, некоторые плохо поддерживаются, другие дорогие, и все добавляют сложность там, где она не нужна.
Визуальное тестирование заслуживает лучшего, чем плагин. Оно заслуживает специализированного инструмента, созданного для этой конкретной задачи, доступного всей команде — как разработчикам, так и нетехническим QA-специалистам.