Заявление об ограничении ответственности: мнения, выраженные в этой статье, являются моими собственными и не отражают мнения моего работодателя или кого-либо еще.
Моментальные тесты не спасают наши потребности в покрытии тестами, как мы от них ожидаем. Фактически, они могут быть совершенно противоположными. В этой статье мы обсудим, что такое тест снимков и как более эффективно использовать их в своем коде.
Что такое тест снимка?
Типичный тестовый пример моментального снимка визуализирует компонент пользовательского интерфейса, делает снимок, а затем сравнивает его с эталонным файлом моментального снимка, хранящимся вместе с тестом. Тест завершится неудачно, если два снимка не совпадают: либо изменение является неожиданным, либо эталонный снимок необходимо обновить до новой версии компонента пользовательского интерфейса.
источник: https://jestjs.io/docs/snapshot-testing
Это нормально при тестировании статических страниц или небольших компонентов, но современные одностраничные приложения полны динамических, постоянно меняющихся представлений, которые зависят от передаваемых им данных.
Любой компонент, размер которого превышает один элемент, такой как button span или div, скорее всего, будет иметь изменяющееся содержимое. Поскольку мы обычно не тестируем функциональность с помощью нашего стиля, макета и текстового содержания, добавление теста моментального снимка не приносит особой пользы.
Возможно, это даже помеха.
Моментальные тесты могут снизить продуктивность разработчика
Допустим, у нас есть компонент Button, и мы импортируем его на страницу оформления заказа:
В этом примере у Button уже есть тест снимка. Но теперь мы создаем страницу оформления заказа, которая импортирует эту кнопку. А поскольку наши коллеги не утвердят пул-реквест без некоторого тестирования, мы добавляем тест с моментальным снимком, потому что он прост и внушает чувство безопасности. Вот тут-то и начинаются проблемы.
Перенесемся на несколько недель, и мы сделали снимки 30 страниц в нашей кодовой базе, которые импортируют Button, и нам нужно внести изменения в Button. Итак, мы вносим наши изменения и обновляем локальный тест моментального снимка для Button, но когда мы переходим к внесению наших изменений ... внезапно все 30 этих страниц нуждаются в обновлении своих тестов моментального снимка. Утомительная и бессмысленная задача.
Так как же это исправить?
Используйте намерение при написании модульных тестов
В вышеупомянутом примере с кнопкой мы можем запустить npm run test —- -u, чтобы обновить за нас моментальный снимок, но все, что мы сделали, это добавили еще одну бесполезную задачу для разработчиков перед фиксацией своего кода. Мы потеряли цель модульного тестирования - убедиться, что наш код выполняет критически важные вещи, несмотря на наши постоянные итерации и улучшения. Вместо того, чтобы делать снимок всего компонента, мы должны фиксировать критически важные вещи на странице оформления заказа, например, список элементов. Вот лучший способ проверить тот же код:
Детальный подход к модульному тестированию с меньшей вероятностью потребует обслуживания, поскольку разработчики повторяют и добавляют к существующим функциям. Это также означает, что когда тесты терпят неудачу, это потому, что основная цель компонента изменилась. Теперь нам нужно подумать о том, как должны измениться наши тесты, а не просто запустить команду для их обновления.
Когда мне следует использовать тест снимков?
Я обнаружил, что тесты моментальных снимков чрезвычайно эффективны в двух случаях:
- При тестировании небольших статических компонентов мы можем использовать запросы DOM / React для создания встроенных снимков, чтобы убедиться, что мы выполняем критически важную логику рендеринга в нашем компоненте. Именно так большинство библиотек тестирования предлагают использовать снимки состояния вместо захвата целых страниц или крупных функций.
- При создании повторно используемого кода, такого как библиотека компонентов, тест снимка может помочь разработчикам полагаться на более простые компоненты, которые будут выглядеть одинаково независимо от того, где они используются.
Когда НЕ следует использовать тест снимков?
- При тестировании больших компонентов или целых веб-страниц, за исключением давно существующих статических страниц, таких как документация.
- При тестировании функциональности. Вместо этого попробуйте по возможности использовать утверждения.
И последнее о предотвращении регрессов
Распространенный аргумент в пользу добавления тестов моментальных снимков - предотвращение регрессий. Большинство современных кодовых баз уже используют автоматическое тестирование, такое как Cypress или Capybara, и имеют штат сотрудников по контролю качества, вся работа которых заключается в запуске наборов тестов, которые гарантируют, что мы не вызовем непредвиденных регрессий. Инструмент pdiff также может быть чрезвычайно полезным при попытке предотвратить регресс. Модульное тестирование со снимками не предназначено для замены каких-либо из этих невероятных инструментов или процессов, уже имеющихся в нашем распоряжении.
