За последние годы скорость развития технологий для создания фронтенд‑приложений выросла в разы. Новые фреймворки, библиотеки, инструменты сборки и подходы к разработке появляются практически каждый год. Однако, несмотря на это, основная точка взаимодействия пользователя с продуктом остаётся неизменной — это интерфейс. Именно он формирует впечатление о продукте и, по сути, является окончательной «витриной» всей вашей работы.
И тут возникает серьёзное испытание для разработчиков и тестировщиков: интерфейсы становятся всё сложнее, контент — динамичнее, а ожидания пользователей — выше. Чем сложнее приложение, тем больше шансов, что в нём появятся визуальные или функциональные баги. Порой вовсе незначительное изменение кода нарушает вёрстку на одной из страниц, ломает адаптивность или просто перестаёт нажиматься кнопка «Купить».
Традиционные подходы к тестированию на многих уровнях уже не успевают за реалиями разработки: ручное тестирование становится слишком трудоёмким, а написание unit‑ или end‑to‑end‑тестов не всегда позволяет отследить именно визуальные изменения. И здесь на помощь приходит методология скриншотного тестирования — мощный инструмент для выявления визуальных багов, появляющихся в интерфейсе. Он позволяет убедиться в том, что ваш продукт отображается так, как задумано, и избавляет команду от многих сюрпризов.
Давайте разберёмся, почему скриншотное тестирование становится необходимостью и как оно помогает справляться с вызовами современного фронтенда. Все кейсы будем разбирать на примере использования опенсорс‑инструмента Testplane от команды Yandex Infrastructure в связке с его html‑отчётом.
Методологии тестирования фронтенда
Типичная задача фронтенда — внести в одну часть приложения изменение, которое может случайно повлиять на другие элементы. Например, вы изменили стили одного блока, а это привело к неожиданным последствиям из‑за каскадных эффектов CSS.
В современной фронтенд‑разработке используются разнообразные подходы к тестированию. Это гарантия того, что пользовательский интерфейс и функциональность работают так, как задумано. Однако, несмотря на их эффективность, у каждого типа тестирования есть свои ограничения.
Давайте вспомним основные типы тестирования фронтенда.
Unit-тестирование
Unit‑тесты проверяют отдельные части кода, такие как функции, компоненты или модули. Это базовая методология, которая помогает гарантировать, что минимальные единицы функциональности приложения работают корректно. Например, тесты могут проверять, рендерится ли React‑компонент с правильными данными или вызывается ли нужная функция по событию.
Ограничение подхода. Unit‑тесты сосредоточены на функциональной целостности и не дают никакого визуального представления об элементе. Даже если компонент с технической точки зрения работает, отступы, шрифты, цвета и общая стилистика могут быть нарушены, а unit‑тест это просто пропустит.
Интеграционное тестирование
Этот вид тестирования показывает, как компоненты или модули взаимодействуют друг с другом. Например, вы можете проверить, как форма отправляет данные и возвращает сообщение после успешной отправки.
Ограничение подхода. Хоть интеграционные тесты и дают больше информации о взаимодействии элементов, они по‑прежнему не фокусируются на визуальном состоянии интерфейса. Невалидные размеры, шрифты, случайно наложенные друг на друга блоки — всё это может быть совершенно незаметным в таких тестах.
End-to-end-тестирование
End‑to‑end‑тесты (E2E‑тесты) направлены на эмуляцию пути пользователя в приложении: от открытия страницы до выполнения конкретной задачи. Многие современные фреймворки (Testplane, Playwright, Cypress) для тестирования позволяют написать сценарий, который будет выполняться в браузере и взаимодействовать с приложением так, будто это реальный пользователь. Это способ проверить, что пользователь, например, может зайти в свой аккаунт, добавить товары в корзину и успешно оформить заказ. Это мощная проверка всей системы в целом.
Ограничение подхода. Основная проблема E2E‑тестирования заключается в том, что оно, как правило, проверяет логику работы приложения, а не внешний вид. Даже если тест проходит успешно, это не гарантирует того, что кнопка находится на своём месте, шрифт читаем, а изображения корректно отображаются.
Ручное тестирование
Тестировщик вручную проходит приложение, проверяя функциональность, пользовательский опыт и внешний вид продукта. Ручное тестирование позволяет заметить то, что нельзя автоматизировать в тестах.
Ограничение подхода. Этот способ тестирования наиболее зависим от человеческого фактора. Тестировщик может пропустить мелкие визуальные баги или просто не заметить, что элемент слегка сместился или пропал на одном из экранов. Ручное тестирование также отнимает много времени и плохо масштабируется для больших проектов.
Таким образом, скриншотное тестирование (visual regression testing) становится той недостающей частью, которая позволяет закрыть важные кейсы, упускаемые другими подходами.
В какие моменты поможет скриншотное тестирование
Скриншотное тестирование — это специализированный тип автоматизированного тестирования, который фокусируется на визуальной стороне приложения. Основная идея заключается в том, что при каждом запуске тесты создают скриншот страницы или отдельных компонентов фронтенда и сравнивают их с эталонными изображениями. Любое заметное отличие — например, изменение цвета, смещение блока, удаление элемента — фиксируется как баг.
Важно отметить, что скриншотное тестирование не является заменой другим подходам, но прекрасно их дополняет. Оно особенно эффективно в случаях, когда проект состоит из множества компонентов и разрабатывается большой командой. Кроме этого, есть разные подходы скриншотного тестирования — начиная от скриншота состояния отдельного компонента в изоляции и заканчивая скриншотом всей страницы в E2E‑тестах.
Так когда же помогают скриншотные тесты? Давайте посмотрим на несколько примеров ниже.
Отлавливание некритичных визуальных багов. Самый банальный пример — это те самые правки, которые привели к изменению интерфейса. Например, изменили стили формы авторизации, и теперь пользователь видит совсем не то, что задумано.
При этом даже по скриншоту видно, что пользователь всё равно сможет авторизоваться, но впечатления от сервиса останутся негативными.
Поиск интерфейсных багов, приводящих к нарушению работы сервиса. Рассмотрим ту же форму, но с более серьёзными правками.
Согласитесь, что такой случай будет более критичен: теперь пользователь лишён возможности залогиниться в сервисе. При этом обычный unit‑тест здесь пройдёт успешно, так как по факту нужное поле для ввода пароля на странице присутствует.
Общий анализ всей страницы. В предыдущих примерах мы рассматривали скриншотный тест, проверяющий конкретный элемент на странице. Но с помощью скриншотов можно проверять и всю страницу целиком. Да, при таком подходе может быть больше шумов в виде незначительных диффов, связанных с рендерингом браузера, но такой подход позволяет быстро оценить общее состояние страницы вашего сервиса. А правильный инструмент для анализа результатов теста поможет вам найти и провалидировать все изменения:
Проблемы скриншотного тестирования
Скриншотное тестирование — мощный инструмент для визуального тестирования, однако и оно не лишено недостатков и может вызывать определённые трудности в процессе тестирования. Тем не менее не стоит переживать: для каждой из этих проблем существуют оптимальные решения, которые помогут эффективно справиться с вызовами.
Чувствительность к незначительным изменениям (ложноположительные срабатывания)
Скриншотное тестирование фиксирует в визуальном отображении даже минимальные изменения — например, из‑за антиалиасинга, — которые могут быть несущественны, или незначительные изменения цвета, которые никак не влияют на пользовательский опыт.
Решение. Настройка допустимого порога отклонения (threshold) при сравнении скриншотов. Это позволяет игнорировать незначительные пиксельные различия, которые не влияют на визуальное восприятие.
Проблемы с динамическим контентом
Скриншоты могут быть неточными из‑за содержания, которое динамически генерируется или анимируется (например, анимация элементов интерфейса, динамическая подгрузка данных и т. д.), что приводит к фиктивным ошибкам.
Решение. Замена динамического контента статическими заглушками через мокирование данных, использование контролируемых фиктивных данных. Идеальное окружение — это статическое воспроизводимое окружение, которое быстро и стабильно предоставляет интерфейс для тестирования. Кроме этого, динамические элементы можно игнорировать при сравнении скриншотов с эталоном.
Зависимость от размера экрана и окружения
Скриншотное тестирование часто чувствительно к различиям между устройствами (десктоп, планшет, мобильные устройства) и окружением (разрешение экрана, DPI, операционная система, браузер). Например, компонент, который корректно отображается на разрешении десктопа, может казаться «сломавшимся» на мобильных устройствах.
Решение. Проводить тестирование при заранее заданных настройках (например, размер экрана, DPI, версия браузера) для различных разрешений и устройств. Наиболее частый вариант решения данной проблемы — использовать облачные устройства (например, BrowserStack или Sauce Labs) для тестирования в различных операционных системах, браузерах и устройствах. Реже выбирают вариант с Docker‑образами, в которых собрано всё необходимое окружение для запуска тестов.
Длительное время тестирования
Очевидно, что для скриншотного тестирования нужно открывать страницу проекта в тестируемом устройстве, а это всегда будет занимать заметное время. И сравнивать скриншоты по мере роста масштабов проекта — долго. Чем больше страниц и состояний нужно протестировать, тем больше будет тестов, а следовательно, выше нагрузка на CI/CD‑пайплайн.
Решение. Ограничивать скриншотное тестирование критическими компонентами и страницами, где наибольшая вероятность визуальных ошибок. Также можно параллельно выполнять тесты для ускорения обработки. Ещё подойдёт вариант тестировать компоненты в изоляции друг от друга и использовать максимально быстрое окружение. Или же можно применять фреймворки, оптимизированные для масштабирования выполнения такого рода тестирования.
Дополнительные накладные расходы на обновление эталонных скриншотов
Каждое изменение в коде или дизайне требует обновления эталонных скриншотов, что создаёт дополнительную нагрузку на команду. Неправильное обновление эталона может скрыть реальную ошибку.
Решение. В связке с фреймворком для тестирования можно использовать удобный UI для просмотра изменений эталонов и их быстрого обновления.
Стоимость внедрения скриншотного тестирования
Для небольших или менее критичных проектов скриншотное тестирование может быть слишком затратным по времени и ресурсам, потому что нужно дополнительно изучать фреймворк и писать с помощью него тесты.
Решение. Использовать фреймворки с максимально простым API или с возможностью автоматической генерации скриншотных тестов.
Testplane + Storybook
Выше описан ряд проблем, с которыми можно столкнуться при внедрении и использовании скриншотных тестов. Но не стоит паниковать раньше времени — совсем не обязательно думать о том, как написать эти тесты, как избавиться от проблем нестабильности окружения или как сократить время выполнения тестов. Все эти проблемы могут решить разные инструменты — например, Testplane в связке со Storybook.
Storybook, инструмент для разработки UI‑компонентов, предоставляет возможность визуализировать их в разных состояниях в полностью изолированной среде. Такая среда, напоминающая шоурум, отлично подходит для проведения скриншотного тестирования: изоляция позволяет тестам работать значительно стабильнее и быстрее по сравнению с E2E‑подходом.
С помощью плагина @testplane/storybook можно автоматически проверять изменения любых компонентов через скриншотное тестирование. Достаточно описать нужный компонент в Storybook, а Testplane при запуске автоматически сгенерирует все необходимые тесты, прогонит их в нужных браузерах и предоставит визуальный отчёт для обновления скриншотов.
На видео ниже можно наблюдать работу с html‑отчётом, который автоматически откроется в вашем браузере после выполнения команды npx testplane --storybook. При открытии отчёта мы в интерфейсе слева сразу видим список сгенерированных тестов. Над деревом тестов находятся элементы фильтрации / группировки тестов, а также элементы управления запуском тестов.
При нажатии на кнопку Run по умолчанию запустятся все автосгенерированные тесты, но также есть режимы запуска только упавших или вручную выбранных (с помощью чекбоксов) тестов. По завершении тестирования все тесты прокрасятся в соответствующие цвета, а для каждого упавшего теста в дереве можно посмотреть превью с причиной падения.
При выборе конкретного теста справа будет отображаться более подробная информация о нём. Например, время выполнения теста, тестируемый URL, путь к story‑файлу, из которого был сгенерирован данный тест, и многое другое (в эту секцию можно выгружать любые кастомные параметры, которые необходимы пользователю).
Ниже располагается список шагов теста с разбивкой по времени выполнения каждого из них. Это будет полезно при добавлении дополнительных шагов сценариев, которые можно описать человекопонятным языком с помощью команды runStep (в таком случае в отчёте вместо набора команд автоматически будет отображаться ваше описание).
В конце всех шагов упавшего теста располагается причина падения. В нашем случае причиной является скриншотный дифф — результат работы команды assertView. В этой секции вы можете использовать разные варианты для анализа скриншотов: side‑by‑side, наложение одного скриншота на другой, поочерёдное переключение скриншотов, подсветка диффа по клику и т. д. А также присутствует кнопка для принятия скриншота, после нажатия на которую эталонный скриншот обновится, и при последующем перезапуске теста будет использоваться уже обновлённое изображение.
А если вам лень проходить по каждому тесту отдельно и обновлять скриншоты, в управляющих элементах над деревом тестов (слева вверху) есть кнопка, которая обновляет все скриншоты в отчёте в один клик.
В итоге у нас в распоряжении оказывается готовый Storybook со всеми компонентами, которые автоматически будут протестированы во всех описанных состояниях. Это максимально изолированные и стабильные тесты, а выполняться они будут за секунды.
Подробнее о том, как настроить автоскриншотные тесты, можно почитать в документации Testplane, в разделе «Скриншотное тестирование со Storybook». Также можно попробовать позапускать тесты вживую на уже готовом примере на GitHub.
Если у вас возникнут вопросы по использованию инструмента — у нас есть чат сообщества в Telegram. А если захотите узнать больше про команду, которая его разрабатывает, то заглядывайте в канал Yandex Infrastructure.
Скриншотное тестирование становится важной частью контроля качества. С его помощью можно с лёгкостью зафиксировать визуальные изменения, которые могут быть незаметными для unit‑ или E2E‑тестов. В связке с другими видами проверки оно помогает быстро обнаруживать ошибки в интерфейсе, поддерживая стабильность и корректность приложения.
А если вам интересна тема скриншотного тестирования или тестирования интерфейсов в целом, задавайте вопросы или делитесь своим опытом в комментариях — обсудим!
