Snapshot и визуальные регрессионные тесты
↑ 6.3 Качество кода и тестирование: продвинутый уровень · ← Предыдущая · → Следующая
Зачем это на собесе
Snapshot-тесты легко превратить в шум; важно знать, когда они полезны, а когда вредны.
Snapshot-тесты (структура)
expect(formatInvoice(data)).toMatchSnapshot()
expect(user).toMatchInlineSnapshot(`{ "id": 1, "name": "Анна" }`)Хороши для стабильных сериализуемых результатов: конфигурации, ответы форматтеров, AST. Плохи для больших DOM-деревьев: разработчики слепо обновляют -u.
Правила: маленькие и осмысленные снимки, ревью изменений снимков как кода, предпочитать явные expect для важных свойств.
Визуальные регрессионные тесты
Сравнивают пиксели скриншотов с эталоном.
await expect(page).toHaveScreenshot('dashboard.png', { maxDiffPixelRatio: 0.01 })Инструменты: Playwright toHaveScreenshot, Storybook + Chromatic, Percy, Loki.
Стабильность скриншотов
- фиксированный viewport, шрифты, локаль, часовой пояс;
- отключить анимации и мокать даты;
- эталоны генерировать в том же окружении, что и CI (Docker-образ Playwright);
- скрывать динамические области (
mask).
Когда использовать
Дизайн-система и библиотека компонентов — да. Обычные страницы с динамикой — осторожно.
Вопросы с ответами
Чем плохи snapshot-тесты?
Большие снимки не показывают намерение и обновляются механически. Изменение приходит и утверждается без анализа.
Как сделать визуальные тесты стабильными?
Единое окружение (Docker), фиксированные шрифты и viewport, отключённые анимации, мок данных, маски на динамические блоки.