Пару лет назад на одном из крупных митапов для тимлидов в Москве я услышал несколько интересных высказываний о тестах:
“Юнит тесты в ограниченном количестве нужны. Но имеет смысл их писать всего наверное два.”
Более осмысленная:
“Юнит тесты удваивают или утраивают стоимость разработки”
и та самая:
“Юнит тесты - это зло”
Меня задели эти утверждения, но я понимал где скрываются корни этой проблемы.
Как юнит тесты могут убить проект
Первый раз я всерьез познакомился с юнит тестами около 10 лет назад. Компания в которой я тогда работал старалась использовать лучшие практики существовавшие на тот момент. Одной из них (вместе с Agile/Scrum/Kanban) был eXtreme Programming с техникой TDD. В лучших традициях XP тесты были возведены в абсолют и тестировать нужно было абсолютно все. Местами получалось неплохо но в какой-то момент мы стали замечать что поддержка тестов стала приносить много проблем. Даже маленькую задачу было сложно оценить потому что команда не могла предсказать сколько тестов придется чинить. Но об отказе от тестов не было и речи - тесты виделись серьезной инвестицией в стабильность системы.
Был 2010 год, мы программировали как могли. Провинциальные разработчики с большой помощью приезжих звезд лихо писали классы на тысячу строк и стоически покрывали их юнит тестами которые разрастались вдвое больше. Любое изменение кода приводило к падению десятка тестов и поддержка этих тестов занимала в разы больше времени чем написание кода. Прогон всех тестов стал доходить до часа, приходилось дорабатывать инструментарий чтобы запускать тесты в несколько потоков и по частям.
Тесты заставляли нас страдать физически. Для борьбы с тестами часть команды отправили на тренинг в столицу и оказалось что все что мы считали юнит тестами таковым не является. Начался серьезный рефакторинг, самые вопиющие классы и тестами пустили под нож, критические части системы переписали с нуля. Мы сделали колоссальную работу над ошибками и подняли уровень команды. А потом у стартапа закончились деньги.
Хватило бы времени если бы мы не тратили океан времени на поддержку тестов и доработку инструментария, а вложили это время и силы в разработку? Сложно ответить, вопрос с подвохом. Но однозначно тесты были одним из гвоздей которые мы - разработчики - методично забивали в крышку стартапа.
Виноваты ли тесты? Тесты сами по себе очень полезный и эффективный инструмент, но используя его неправильно легко получить результат противоположный ожидаемому.
Воз и ныне там
В 2012 году я сделал доклад по юнит тестами на DevConf
В том же году пообщался с командой из Санкт Петербурга и обсудили их проблемы с тестированием. За последние 2 года я поговорил о тестах с оффлайн командами из Москвы и распределенными командами с разработчиками со всего мира: за 8 лет вопросы не изменились
Разработчики готовы писать тесты, но требуют на них больше времени. Бизнес готов инвестировать в стабильность системы, но хочет уменьшать time to market а не увеличить его. Часто обсуждение заходит в тупик - внедрение тестов вскрывает проблемы к решению которых команды не готовы. Но и отказываться от тестов никто не спешит.
Информации по тестам в интернете очень много, но большинство авторов не утруждает себя описанием фундамента юнит тестирования и TDD, переходя к написанию тестов на калькулятор.
Я хочу исправить это и помочь построить базу на которую можно опираться используя в работе такой сложный и полезный инструмент как юнит тесты.