Как тесты убивают продукт
Обычная история: вы начинаете новый проект, команда полна энтузиазма, дает реалистичные эстимейты и часто в них попадает. Вместе с фичами начинают появляться баги.
В какой-то момент команда решает что нужно писать тесты. Разработчики рьяно берутся за дело, предсказуемо начинают расти эстимейты, но бизнес готов инвестировать в качество продукта. Баги продолжают появлятся.
Бизнес логика усложняется. Код, сперва простой и лаконичный, быстро разбухает. Отсутствие заранее продуманного дизайна начинает давать о себе знать - код становится все сложнее читать и править. Начинают возвращаться баги которые чинили ранее.
Любое изменение кода вызывает лавину упавших тестов. Так как задачу нельзя сдать с упавшими тестами разработчик начинает копаться в тестах: нужно понять почему тесты упали и актуализировать их или починить код. Но чаще актуализировать тесты.
С ростом проекта качество эстимейтов начинает снижаться. Все чаще задачи завершаются позже оговоренного срока. Баги начинают накапливаться и приоритезироваться потому что разработчикам уже некогда ими заниматься.
В какой-то момент вместо эстимейта разработчики говорят, что сама задача займет 20 минут, а починить тесты - как получится.
Разработчики не могут оценить задачу а бизнес не может планировать, но все - по объективным причинам. Ситуация странная, но в ней никто не виноват кроме тестов. Но и бизнес и разработчики согласны что тесты нужны а предложения выкинуть тесты не встречают одобрения.
Как исправить
Не нужно ждать пользы от тестов в будущем - для 90% проектов это будущее никогда не настанет. Тесты должны приносить пользу сегодня.
Нужно трезво оценить плюсы и минусы уже написанных тестов. Честно ответить себе работают ли тесты на благо компании и если нет - перестать пинать труп лошади.
Не нужно отказываться от идеи автоматических тестов, но перед перезапуском нужно извлечь как можно больше уроков и убедиться что предыдущий опыт не повторится.
Необходимо заботиться о здоровье кода - не стоит думать что смена стратегии тестирования при неизменном коде принесет качественно другой результат.
Программирование+1
Есть одна важная причина писать тесты, и юнит, и интеграционные, и покрывающие.
Проверить только-что написанный... Читать дальше
Проверить только-что написанный код. Это самая большая польза, которую тесты приносят.
TDD это по определению тесты написанные до кода. Самая большая польза от TDD это не фиксация кода в рабочем положении, а помощь в создании дизайна кода и реализации. В статье "Принципы F.I.R.S.T. и почему их нужно соблюдать" я привожу мнение Роберта Мартина о том что тесты написанные после кода то можно решить что покрывать тестами слишком сложно или не целесообразно (код ведь уже есть и работает - зачем выполнять лишнюю работу которая не принесет новой ценности) или код может оказаться не тестируемым.
Писать тесты - нужно уметь. Этим должны заниматься QA, но QA соответвующего уровня, т.к. это такая же программа, как и тестируемый код.
Это отдельная тема и в рамках TDD тестировщики ничем не могут помочь. Разработчик пишет тест зная что внутри (белый ящик), тестировщики тестируют черный ящик (не знают что внутри, но как-то работает и это проверяем).
Писать тесты - нужно уметь.
Об этом создавалось это сообщество и я буду рад если через какое-то время больше программистов сможет писать качественные тесты.