Когда, зачем, сколько и для чего писать юнит-тесты

Если подумать, каждая сложная система состоит из большого количества менее сложных частей. Например, у машины есть двигатель, колеса, кресла, руль, стёкла. Все эти части вместе составляют автомобиль, которым можно пользоваться только потому, что все его части правильно работают и хорошо подогнаны друг к другу. Каждая из таких частей на английском языке называется «unit». И это именно тот unit, который тестирует unit-тесты.

Что нужно, чтобы написать хороший unit-test?

Хороший тест должен обладать следующим:

– Изоляцией тестируемого компонента: если одновременно тестируется больше одного компонента, то это уже интеграционный тест; – Определением тестируемого поведения: очевидный пункт, и понятно, что это поведение должно относиться к тому модулю, который вы хотите тестировать; – Формальные условия успеха и неуспеха теста: второй очевидный пункт, но без этих условий мы не сможем понять, пройден тест или нет (для модульного теста нет понятия «частично прошёл», он или прошёл, или нет.)


Несмотря на то, что все эти пункты не выглядят особенно сложными, первый зачастую вызывает сложности. Большинство систем были придуманы не очень модульными, и для эффективного разбиения на компоненты придётся потратить немало усилий.

Поэтому важно изначально уделять достаточно внимания архитектуре приложения и следовать принципам SOLID, которые очень сильно облегчают дальнейшее тестирование приложений.

Зачем

В первую очередь, писать тесты стоит для того, чтобы экономить своё время (как бы это странно ни звучало). Может показаться, что написание тестов только отнимает время, но это не так. Внесение изменений в код приложения будет каждый раз требовать у вас проверки того, что ничего из ранее работавшего работать не перестало. И с каждым разом это будет занимать всё больше и больше времени, потому что кода будет всё больше и больше.

И здесь на помощь приходят тесты. Единожды написанные, они автоматически проверяют, что всё, что работало, по-прежнему продолжает работать. Так что если вы ловите себя на том, что раз за разом проверяете одни и те же функции приложения — самое время написать тесты, которые будут делать это за вас.

Кроме того, если в какой-то момент вы решите переписать старый код, тесты помогут и в этом. Если они будут успешными, вы будете уверены, что новый код для внешних модулей работает так же, как и старый, и ничего не будет сломано.

Ещё один повод писать тесты – уверенность в том, что исправленная ошибка никогда больше не появится. Думаю, всем знакома ситуация, когда какая-нибудь ошибка появляется снова и снова, хотя вы исправляли её уже несколько раз. Но каждый раз после внесения каких-нибудь изменений – она опять здесь.

Решить проблему могут тесты, которые изолируют эту ошибку и проверяют, что она не никогда не возникает снова.

Нужно ли тестировать вообще всё?

Многие вокруг говорят о том, как это хорошо и правильно — тестировать код. Но так ли это? Весь ли код должен быть покрыт тестами?

В сообществе не существует единого взгляда на этот вопрос. Более того, мнения диаметрально противоположны. Одни говорят, что тестировать надо всё, и каждая строчка кода должна быть покрыта тестами. Другие же, наоборот, считают тестирование лишней тратой времени и убеждены, что хороший тестировщик найдёт все дефекты быстрее и качественнее любых тестов.

Как же быть? Какой точку зрения выбрать? Писать или не писать тесты? Каждый решает это для себя сам, но всё же есть несколько случаев, когда тесты становятся настоящей панацеей.

Сложновоспроизводимое или редкое поведение приложения

Предположим, на тысячный запуск приложения нам нужно показать пользователю красивый pop-up с благодарностью за использование вашего продукта. Код готов, но как его проверить? Самые очевидные пути такие:

Запустить приложение 1000 раз. Это долго: если что-то пойдёт не так, проверять второй раз будет так же долго, как и в первый. А если и в третий раз не получится, то можно легко потратить на проверку несколько недель.

Переделать условие на меньшее число запусков или установить счётчик запусков сразу в близкое к порогу значение. Это просто и не займёт много времени. Но если в какой-то момент вы забудете вернуть на место нормальное значение, такой код и попадёт в продакшн. Не круто.

Написать тестируемый код, отвечающий за это, и сделать тест на ваше условие. Самый простой и безопасный вариант. Всё работает, времени потрачено немного, в продакшн всё точно попадёт правильно и хорошо. Ура.

Такая же точно ситуация и с условиями, которые зависят от даты. Например, вам нужно что-то показывать пользователю только вечером в пятницу. Не будете же вы ждать вечера пятницы для того, чтобы проверить, что всё хорошо?

Моделирование работы сервера. Часто бывает, что API разрабатывается параллельно с приложением, и, хотя у вас уже есть его описание, самого API всё ещё нет. Кто-то в таком случае скажет: «Повезло, сегодня короткий день» и пойдёт домой. А кто-то опишет поведение зависящего от API кода тестами, передаст в них данные из описания API и сможет отладить весь остальной код.

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

А вот писать или не писать тесты каждый раз, решать вам: готовы ли вы тратить время на то, что в итоге может и не окупиться?

Остались вопросы? Напишите в комментариях!