В прошлом посте я обсудил документацию, которую неплохо бы писать в большинстве случаев. См также Как сделать тестирование приложений проще и читабельнее
Сегодня поговорю про тесты.
На мой взгляд, с тестами всё обстоит менее радикально, чем с документацией. Т.к. я работаю в веб разработке, то учтите, что мои рассуждения распространяются только на этот сегмент. Расскажу свои мысли исходя из практики. Не хочу теоретизировать и лезть в другие, малознакомые области.
Тесты надо писать
Когда у вас много разветвленной бизнес логики и проект постоянно развивается. Тесты помогут быть немного более уверенными при внесении изменений в уже существующий код. И еще они сильно сэкономят вам время на тестировании всех юзер кейсов приложения.
Если ваш менеджер говорит, что написание тестов – это трата времени и вообще вам тут за фичи платят, а не за тесты, то покажите ему, сколько времени стоит проверить все юзер кейсы руками (допустим, минут 30-60, но бывает, что и много часов), а потом запустите тесты, и они пробегут у вас за 3 минутки. Если менеджеру не хватит сообразительности посчитать этот несложный математический пример, то кивните и не пишите тесты. Спустя пару месяцев, две еле выпущенные фичи и пяток багов на проде повторите еще раз предыдущую итерацию. Возможно, в этот раз сработает лучше.
Тесты не надо писать
– Если вы у вас особой логики нет, а вы делаете инфосайтик, где просто выводите очередной блок новостей из базы.
– Если вы один раз сделали проект и забыли про него. Поддерживать не надо
– Если вы просто хотите написать тест ради теста, чтобы почувствовать себя более программистским программистом, ведь в твиттере, на ютубе и хабре говорят, что кто не тестит – тот не программист.
Дымовой тест (Smoke test)
Иной раз вполне достаточно написать самый минимальный набор тестов, который будет подтверждать общую работоспособность вашего приложения. Например, у вас есть чудесный одностраничный сайт автошколы, на котором есть расписание и три рекламных блока. Напишите тест, который проверит, что страница отдается со статусом 200 и получает контент из футера (то есть загружается до конца) и вам для спокойствия этого будет более чем достаточно.
Если развернуть мысль немножко шире, то дымовые тесты вы конечно можете писать не только для тривиальных проектов, но и для сложных. В этом случае сначала запускайте их, чтобы проверить, что приложение базово работоспособное, а потом уже оставшийся мильён тестов, чтобы проверять детали.
Итог
Смотрите сами, насколько целесообразно написать тесты и на что конкретно. Не слушайте радикалов, которые говорят, что нужно 100% покрытие кода тестами, или наоборот, тесты – трата времени. Думайте, анализируйте реальную пользу, которую можете получить.
Автор: @eantonov
Телеграм: Тимлид Очевидность
Обсудить: Чат канала в телеграм
Бывают методы довольно большие, которые можно покрыть 200ми модульными тестами и каждый тест со своей настройкой. Раньше я писал тесты на несколько тысяч строк кода, с надеждой, что больше к ним не вернусь и не придется разбираться в них.