При тестировании кода вы столкнетесь с множеством различных проблем, которые необходимо решить. К сожалению, приложение обычно не работает со строго чистыми функциями и без каких-либо побочных эффектов. Поэтому нам приходится имитировать различные вещи, или моделировать окружение, внедрять зависимости и делать множество других вещей. Если вы когда-нибудь работали над фронтендом и пытались писать тесты, вы наверняка заметили, что особенно сложно тестировать компоненты. Одним из возможных решений являются снапшот-тесты.
Что такое моментальное тестирование?
Идея снапшот-тестирования довольно проста. Вы создаете свой компонент и делаете снимок, если все готово. С этого момента тест будет терпеть неудачу, когда обнаружит любое изменение в выводе компонента. В этих случаях у вас есть два возможных решения: Исправить компонент, чтобы он вел себя как раньше, или создать новый моментальный снимок.
Что не так со снапшот-тестированием?
Звучит интригующе, не так ли? Но есть некоторые проблемы со снапшот-тестированием.
Прежде всего, при тестировании моментальных снимков предполагается, что компонент делал все правильно, когда был сделан моментальный снимок. Это может привести к ложному чувству безопасности. Кроме того, моментальные тесты ничего не говорят об ожидаемом поведении компонента. Это простое «Он делает то же, что и раньше».
И тогда вам придется думать о том, что должно произойти, если snapshot-тест не сработает в будущем. Если вы изменили компонент, то, конечно, он должен не сработать. Но знаете ли вы, делает ли он сейчас то, что должен делать? Нет, не на основе моментального теста. Что делает разработчик сейчас? Он/она просто предполагает, что с изменениями все в порядке, обновляет снапшот и проталкивает изменение. Готово.
Итак, единственное, на что способен снапшот-тест, — это уведомлять об изменениях, произошедших в компоненте. Ну, это то, чего вы ожидаете, когда разработчик работает над кодом.
Что вы должны делать вместо этого?
Просто и понятно: Напишите специальные тесты для конкретных ожидаемых поведений. Старайтесь отлавливать крайние случаи и улучшать тесты по ходу дела. И особенно убедитесь, что вы пишете тесты для всех ошибок и проблем, которые вы обнаружите в будущем.
Конечно, мы не можем предполагать, что разработчики будут думать обо всех возможных крайних случаях и состояниях ошибки. Точечное тестирование их тоже не отловит. Для проверки «непредсказуемого» поведения существуют такие методы, как случайные тесты или фазз-тестирование (fuzzing).
Всегда ли моментальные тесты ошибочны?
Нет. Если вы уверены, что они не заменяют «нормальные» тесты. Они могут быть полезны в дополнение к обычным тестам для проверки неожиданных изменений, которые вы могли бы не заметить в противном случае. В остальном их польза, на мой взгляд, весьма ограничена, особенно потому, что они могут не сработать даже при небольших «технических» изменениях — например, пробелах — которые не окажут никакого влияния на функциональность или фактическое представление компонента.
Спасибо, что прочитали. Мне интересно услышать ваше мнение о тестировании моментальных снимков ниже. Может быть, я упустил какие-то примеры использования? Дайте мне знать.