Как протестировать более 40 UI-компонентов за минуту: ускоряем скриншот-тесты

Спасибо за комментарий! Да, вы абсолютно правы - проблема с разностью рендеринга шрифтов и сглаживания (локально на macOS/Windows против Linux в CI) хорошо известна. Мы знаем, что она решается через докеризацию окружения или настройку допустимого порога различий (failureThreshold). Однако мы сознательно решили оставить CI на второй этап развития по двум главным причинам:

• Усложнение флоу разработки и работы с артефактами. Если тесты гоняются только на CI и там падает скриншотный тест, процесс обновления эталонов превращается в нелегкий квест. Разработчику нужно: пойти в упавшую сборку, скачать артефакты, проанализировать diff-картинки, локально запустить Docker для генерации «линуксовых» эталонов, закоммитить их и снова запустить пайплайн. Локальный запуск позволяет поправить код, одной командой (npm run screenshot:update) обновить скриншоты и сразу увидеть результат. Для нас сейчас критически важен бесшовный DX (Developer Experience).

• Проверка гипотезы и MVP. Для нашей команды визуальное регрессионное тестирование - это принципиально новый инструмент в проекте. Нам важно было запустить его максимально быстро, получить первую стабильную версию без ложных срабатываний и доказать бизнесу и команде его ценность. Делать это локально - проще и безопаснее для старта.

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