Снапшот-тестирование

Снапшот-тест записывает вывод кода при первом запуске — отрисованную разметку, сериализованный объект, сгенерированный файл, — сохраняет его рядом с тестом и затем падает всякий раз, когда новый вывод отличается от сохранённой копии. Это дешёвый способ покрыть площадь, которую утомительно проверять поле за полем, поэтому он распространён для деревьев UI-компонентов, форм ответов API и генераторов кода. Плата в том, что снапшот-тест утверждает, что вывод не изменился, а не что он правильный. Это различие и порождает характерный отказ: появляется диф, автор невнимательно его читает, запускает команду обновления — и настоящая регрессия попадает в репозиторий в виде принятого снапшота. Крупные снапшоты усугубляют дело: реальная однострочная проблема невидима внутри трёхсот строк шума, а любое постороннее изменение перекрашивает в дифе весь файл. Полезными их держат такие привычки: делать снапшоты маленькими и посвящёнными одному поведению; проверять изменения снапшотов на ревью ровно так же внимательно, как изменения исходников; никогда не обновлять пачкой; исключать изменчивое содержимое — метки времени, случайные идентификаторы, негарантированный порядок, — потому что оно даёт нестабильные падения, приучающие команду обновлять не глядя. И дополнять их несколькими явными проверками действительно важных свойств: что поле ошибки заполнено, что итог равен сумме строк, — потому что намерение выражают именно они, а снапшот не выражает его никогда.