Снимки (или Snapshots) в тестах с использованием React Testing Library — это мощный инструмент для проверки визуальной стабильности компонентов. Однако для эффективного использования снимков важно соблюдать несколько лучших практик, чтобы тесты оставались полезными и легко поддерживаемыми. В этой части рассматриваются ключевые принципы работы с снимками, подходы к их применению и ограничения.
Снимки идеально подходят для проверки того, как изменяется разметка компонента. Они предоставляют снимок HTML-кода компонента в момент времени и позволяют зафиксировать изменения. Однако это не означает, что следует использовать их для тестирования логики работы компонентов. Снимки должны быть частью более широкого теста, проверяющего поведение приложения, а не основным способом тестирования функциональности.
Снимок сохраняет не только HTML-разметку, но и все дополнительные атрибуты, которые могут изменяться. Это значит, что при каждом изменении компонентов (например, при добавлении новых классов, изменении стилей или контента) будет меняться и снимок. Важно учитывать, что снимки должны проверяться только в случае действительно значимых изменений в компоненте, а не при каждой незначительной модификации.
Пример использования снимка:
import { render } from '@testing-library/react';
import MyComponent from './MyComponent';
test('компонент соответствует снимку', () => {
const { asFragment } = render(<MyComponent />);
expect(asFragment()).toMatchSnapshot();
});В этом примере asFragment() возвращает фрагмент DOM,
который можно сравнить с предыдущим снимком. Если разметка компонента
изменится, тест будет помечен как неуспешный, что позволяет отслеживать
нежелательные изменения.
Частое использование снимков может привести к тому, что тесты будут покрывать слишком многие аспекты, включая те, которые не имеют значения для функциональности компонента. Это увеличивает время работы тестов и делает их сложными для поддержки. Снимки не должны проверять каждый мелкий аспект отображения компонента, а только ключевые визуальные изменения.
Если компонент слишком часто меняется, лучше использовать более целенаправленные тесты, проверяющие важные моменты: отображение текста, наличие элементов, правильное состояние интерфейса и так далее.
Когда компонент обновляется, могут возникнуть ситуации, когда необходимо обновить снимок. Важно понимать, что обновление снимка должно происходить только после осознанных изменений в компоненте. Это позволяет сохранить целостность тестов и избежать ложных срабатываний, когда компонент меняется без изменений в функциональности.
Пример обновления снимка:
jest --updateSnapshotОднако стоит избегать регулярного обновления снимков без необходимости, так как это может привести к нечистоплотному тестированию, где каждый фиксированный тест будет постоянно обновляться.
Иногда компоненты имеют различные состояния, которые могут требовать разных снимков (например, компоненты, которые ведут себя по-разному в зависимости от пропсов или состояния). В таких случаях рекомендуется делать снимки для каждого из этих состояний, чтобы обеспечить точную проверку всех вариантов поведения компонента.
Пример с параметризацией:
test.each([
['состояние 1', { prop1: 'значение1' }],
['состояние 2', { prop1: 'значение2' }]
])('компонент отображается правильно при %s', (description, props) => {
const { asFragment } = render(<MyComponent {...props} />);
expect(asFragment()).toMatchSnapshot();
});Это помогает создать более стабильную тестовую среду, где для каждого состояния будет свой снимок, что значительно уменьшает вероятность ложных срабатываний.
Когда снимок не совпадает с предыдущим, Jest автоматически выведет сообщение о несоответствии, что позволяет разработчику понять, какие изменения произошли в компоненте. Важно правильно трактовать эти сообщения, чтобы убедиться, что изменения корректны и ожидаемы.
Для исключений из снимков, например, если необходимо игнорировать определенные динамичные части компонента (например, время или случайные значения), можно использовать дополнительные методы для фильтрации этих элементов перед созданием снимка.
Пример исключения динамичной части:
test('компонент отображает стабильный снимок', () => {
const { asFragment } = render(<MyComponent />);
const snapshot = asFragment();
// Исключаем динамичные элементы
snapshot.querySelector('.time').textContent = 'fixed-time';
expect(snapshot).toMatchSnapshot();
});Это позволяет избежать ненужных изменений снимков, вызванных динамическими значениями, которые не отражают реальные изменения в компоненте.
Когда проект развивается, и компонентов становится больше, важно уметь контролировать инкрементные изменения снимков. Лучше всего обновлять снимки по мере необходимости, избегая массовых изменений, которые могут запутать тестирование и ухудшить читаемость истории изменений.
Когда большое количество снимков обновляется одновременно, рекомендуется разделять обновления на несколько шагов. Это позволяет легче отслеживать, какие изменения действительно были внесены в код и какие из них могут быть потенциально проблемными.
Хотя снимки полезны для визуального контроля, важно не перегружать проект тестами, которые слишком сильно зависят от визуальной составляющей. Вместо этого рекомендуется использовать снимки в сочетании с более традиционными юнит-тестами и тестами взаимодействий, такими как проверка на изменение состояния, отправка событий и т. д. Это поможет поддерживать стабильность тестов и предотвратить ложные срабатывания при минимальных изменениях.
В командной разработке особенно важно синхронизировать работу над снимками между участниками. Перед обновлением снимков нужно убедиться, что все изменения действительно согласованы с командой, чтобы избежать конфликтов и разногласий по поводу того, какие изменения считаются допустимыми.
В больших проектах полезно ввести процедуры ревью снимков, чтобы удостовериться, что обновления снимков происходят только после изменений, которые соответствуют проектным стандартам.
Снимки могут быть полезным инструментом, но они не являются универсальным решением. Например, они не могут тестировать динамические изменения или логику работы компонента, такую как обработка пользовательских событий, асинхронные запросы или сложные вычисления. Эти аспекты должны проверяться с помощью других типов тестов, таких как юнит-тесты или интеграционные тесты.
Кроме того, снимки могут стать трудными для поддержки, если компонент слишком часто изменяется, или если в проекте используется множество снимков для мелких изменений. Это может привести к перегрузке тестов и увеличению времени их выполнения.
Снимки в React Testing Library предоставляют удобный способ для визуального контроля за изменениями компонентов, но их нужно использовать с осторожностью и понимать их ограничения. Чтобы тесты оставались эффективными, следует избегать чрезмерного использования снимков, придерживаться чистоты тестов и регулярно обновлять их только по мере значительных изменений.