Использовали ли вы скриншот тесты

Что проверяют

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

Как отвечать

Каркас на своём опыте:

• инструмент и уровень: скриншоты страниц в Playwright через expect(page).toHaveScreenshot(), скриншоты компонентов из Storybook через Chromatic, Loki или Lost Pixel, облачные сервисы вроде Percy или Argos, BackstopJS в старых проектах;
• одинаковое окружение: рендер шрифтов и сглаживание различаются между ОС и видеокартами, поэтому эталоны снимают в том же Docker-образе, что и в CI. Playwright по умолчанию добавляет платформу в имя файла эталона как раз поэтому;
• борьба с ложными падениями: отключённые анимации и курсор, фиксированные дата и время, моки сетевых данных, ожидание загрузки шрифтов и картинок, маскирование динамических блоков через опцию mask, допуски maxDiffPixels или maxDiffPixelRatio;
• процесс: где лежат эталоны (в репозитории или в облаке), кто принимает изменения, как обновляли после намеренной правки дизайна (--update-snapshots и ревью разницы в PR);
• что это дало: какие баги поймали, например поехавшую вёрстку после обновления UI-библиотеки, и сколько длится прогон.

Примеры и цифры здесь нужны из вашего проекта. Если скриншот-тестов не было, скажите прямо и объясните, как бы внедряли: начали бы с компонентов дизайн-системы в Storybook, где выгода максимальна, а не с целых страниц с живыми данными.

Где спотыкаются

Снимают эталоны на своём Маке, а сравнивают на Linux в CI. Тесты падают на каждом прогоне, и команда перестаёт им верить.

Покрывают скриншотами всё подряд. Любая правка отступа затрагивает сотни эталонов, их обновляют не глядя и пропускают настоящие регрессии.

Считают скриншот-тесты заменой функциональным. Они проверяют внешний вид, но не то, что кнопка действительно отправляет форму.