Тестирование снимков HTML

Тестирование снимков записывает отрендеренный результат компонента или страницы при первом запуске, а при последующих запусках сравнивает новый результат с сохранённым снимком. Любое изменение HTML приводит к сбою теста, пока снимок намеренно не обновят.

Сопоставитель Jest toMatchSnapshot() сериализует значение (в том числе JSX, отрендеренный в HTML) и сравнивает его с сохранённым файлом. npx jest -u обновляет снимки при намеренных изменениях. Тесты служат защитой от случайных изменений при отображении.

Средство запуска тестов Storybook выполняет каждую историю и сохраняет её результат с помощью axe (доступность) и сериализации DOM. В сочетании с Chromatic оно дополнительно выполняет визуальную проверку регрессий: сравнивает изображения на уровне пикселей в дополнение к сравнению DOM.

Percy и Chromatic сохраняют отрендеренные страницы как изображения и показывают визуальные различия. Они выявляют регрессии CSS, которые пропускают снимки DOM (замену шрифта, изменение отступа, сдвиг цвета). Сочетайте снимки DOM (дешёвые и быстрые) с визуальными снимками (дорогими, но комплексными).

Снимки, которые меняются «слишком легко», превращаются в информационный шум. Не включайте в снимки нестабильные значения (даты, идентификаторы, случайные ключи). Используйте сопоставители свойств Jest (expect.any(String)) для полей, которые закономерно меняются между запусками. Снимки должны быть небольшими и сосредоточенными на конкретной проверке.

Различия в файлах снимков в запросах на включение изменений — полноценный материал для проверки. Проверяющие убеждаются, что изменения DOM намеренны и полезны, а также выявляют случайные каскадные эффекты от «простого» изменения CSS. Относитесь к различиям снимков так же, как к любым другим различиям.

Снимки огромного результата рендеринга страницы целиком хрупки — любое небольшое изменение приводит к гигантскому различию. Создавайте снимки на уровне компонентов: каждой кнопки, каждой карточки, каждого FormField. Для рендеринга страницы целиком лучше использовать тесты визуальной регрессии.

Выберите способ сериализации: полный HTML, упрощённый DOM, только свойства или дерево доступности. Каждый формат выявляет разные виды регрессий. Для компонентов интерфейса самый тщательный вариант — полный HTML; для логики, управляемой свойствами, формат «только свойства» дешевле и редко даёт ложные срабатывания.

Самая распространённая причина — рефакторинг, который создаёт эквивалентный, но иначе структурированный HTML. Изучите различие: если изменение намеренное и улучшает код, обновите снимок. Если оно неожиданное, исправьте исходный код. Никогда не запускайте jest -u без предварительной проверки.

Инструменты визуальной регрессии выполняют рендеринг в нескольких браузерах и сообщают о различиях, характерных для конкретного браузера. Используйте это, чтобы обнаруживать CSS, который отображается по-разному в Safari и Chrome — такое часто случается с новыми возможностями раскладки на раннем этапе их внедрения. Без межбраузерных снимков такие регрессии обнаруживаются только при ручной проверке QA.

Тесты снимков необходимы, но недостаточны. Они выявляют непреднамеренные изменения рендеринга, но не логические ошибки — например, когда нажатие кнопки выполняет не то действие. Сочетайте их с модульными тестами поведения и сквозными тестами пользовательских сценариев: каждый уровень выявляет свои виды сбоев.

Тесты снимков выполняются быстро — они сравнивают строки и файлы. Тесты визуальной регрессии медленнее: они отображают пиксели, сравнивают изображения и часто работают в нескольких браузерах. Запускайте снимки при каждой сборке непрерывной интеграции; визуальную регрессию запускайте для каждого PR, но, возможно, не для каждого коммита — в зависимости от доступного бюджета непрерывной интеграции.

Тестирование снимками сохраняет полученный HTML при первом запуске и сообщает о любых изменениях при последующих запусках. Используйте Jest toMatchSnapshot для DOM компонентов, Storybook Test Runner для сценариев, а Percy или Chromatic — для визуальной регрессии на уровне отдельных пикселей. Создавайте снимки на уровне компонентов, а не страниц, исключайте нестабильные значения и внимательно проверяйте различия в PR. Для полного покрытия сочетайте их с модульными и сквозными тестами.