Надо ли писать тесты?

В прошлом посте я обсудил документацию, которую неплохо бы писать в большинстве случаев. См также Как сделать тестирование приложений проще и читабельнее

Сегодня поговорю про тесты.

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

Тесты надо писать

Когда у вас много разветвленной бизнес логики и проект постоянно развивается. Тесты помогут быть немного более уверенными при внесении изменений в уже существующий код. И еще они сильно сэкономят вам время на тестировании всех юзер кейсов приложения.

Если ваш менеджер говорит, что написание тестов – это трата времени и вообще вам тут за фичи платят, а не за тесты, то покажите ему, сколько времени стоит проверить все юзер кейсы руками (допустим, минут 30-60, но бывает, что и много часов), а потом запустите тесты, и они пробегут у вас за 3 минутки. Если менеджеру не хватит сообразительности посчитать этот несложный математический пример, то кивните и не пишите тесты. Спустя пару месяцев, две еле выпущенные фичи и пяток багов на проде повторите еще раз предыдущую итерацию. Возможно, в этот раз сработает лучше.

Тесты не надо писать

– Если вы у вас особой логики нет, а вы делаете инфосайтик, где просто выводите очередной блок новостей из базы.

– Если вы один раз сделали проект и забыли про него. Поддерживать не надо

– Если вы просто хотите написать тест ради теста, чтобы почувствовать себя более программистским программистом, ведь в твиттере, на ютубе и хабре говорят, что кто не тестит – тот не программист.

Дымовой тест (Smoke test)

Иной раз вполне достаточно написать самый минимальный набор тестов, который будет подтверждать общую работоспособность вашего приложения. Например, у вас есть чудесный одностраничный сайт автошколы, на котором есть расписание и три рекламных блока. Напишите тест, который проверит, что страница отдается со статусом 200 и получает контент из футера (то есть загружается до конца) и вам для спокойствия этого будет более чем достаточно.

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

Итог

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

Автор: @eantonov
Телеграм: Тимлид Очевидность
Обсудить: Чат канала в телеграм

Рейтинг
( Пока оценок нет )
Maxyc Webber/ автор статьи
Мне 35 лет. Опыт профессиональной разработки 15 лет. Занимаюсь разработкой и поддержкой корпоративных систем автоматизации бизнеса, а также высоконагруженными проектами. Мне нравится решать нестандартные проблемы бизнеса. Имею опыт формирования команд под проект, налаживания процесса разработки, коммуникации программистов и заказчиков. Есть опыт работы с зарубежными заказчиками (ОАЭ, Польша, Германия, Швейцария).
Понравилась статья? Поделиться с друзьями:
Комментарии: 1
  1. Артём

    Бывают методы довольно большие, которые можно покрыть 200ми модульными тестами и каждый тест со своей настройкой. Раньше я писал тесты на несколько тысяч строк кода, с надеждой, что больше к ним не вернусь и не придется разбираться в них.

Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.