От переводчика. Давид Хейнемейер Ханссон данной статьей поднял острую тему обязательности использования TDD и, даже, возможного вреда от написания тестов перед написанием кода. Именно эта статья послужила лейтмотивом уже пяти встреч на тему жив ли TDD, на которых Давид, Кент Бек и Мартин Фаулер обсуждают достоинства и недостатки TDD, рамки применимости и ограничения. Для тех у кого восприятие устного английского оставляет желать лучшего, SergeyT публикует краткие саммари в своем G+.
Фундаментализм подхода «тесты вперед» как половое просвещение, ограниченное воздержанием: нереальная и неэффективная нравоучительная кампания полная ненависти к себе и стыда.
Сначала все было по-другому. Мое первое знакомство с TDD было похоже на любезное приглашение в лучший мир программирования. Изменить сознание, чтобы продолжить заниматься практикой тестирования там, где тестирования раньше не было вовсе. Я увидел безмятежность хорошо протестированной кодовой базы, и блаженство от чувства уверенности при внесении изменений в код.
Подход «тесты вперед» был замечательными поддерживающими колесиками, он учил меня, как думать о тестировании на более глубоком уровне, но достаточно быстро я отказался от него.
Спустя несколько лет, риторика «тесты вперед» стала громче и злее. Более подлой. И время от времени меня засасывало в воронку фундаментализма, я чувствовал себя плохо от того, что я не следую истинному писанию. В такие моменты я пробовал практиковать «тесты вперед» в течение нескольких недель, только чтобы бросить снова, когда моим проектам становилось хуже.
Это был эффект маятника: гордость, когда я был в состоянии придерживаться буквы учения, и крах отчаяния, когда не был. Это как начинать пить после завязки. Умалчивать и не показываться в обществе. На людях, я, в лучшем случае, говорил, что не всегда пишу тесты перед написанием кода, а, в худшем, продолжал поддерживать этот подход как истинно верный. Я сожалею об этом сейчас.
Может быть, было необходимо использовать подход «тесты вперед», как таран для разрушения отраслевого «жаль, у нас нет автоматизированного, регрессионного тестирования». Может быть, это была притча, которая не должна была стать буквальным описанием ежедневного стиля программирования. Но как бы это не задумывалось, вскоре все пошло не так. И теперь это используется как молот, чтобы сбивать неверующих, как лакмусовая бумажка, чтобы объявить всех остальных непрофессионалами и непригодными к программированию.
Достаточно. Хватит. Меня зовут Давид, и я не пишу тесты перед написанием кода. Я отказываюсь извиняться за это и, тем более, скрывать. Я благодарен за то, что TDD дал возможность увидеть автоматизированное регрессионное тестирование во всей красе, но я давно ушел от догм этого подхода.
Я предлагаю вам критически взглянуть на то, как этот подход влияет на целостность вашего дизайна. Если вы готовы честно принять во внимание возможность, что это не безусловно хорошо, то выбирайте красную таблетку. Вам может не понравиться то, что вы увидите после.
Так куда мы идем?
Шаг первый: необходимо признать, что есть проблема. Я думаю, что мы сделали это только что. Вторым шагом необходимо сдвинуть спектр тестирования от модуля к системе. Нынешний фанатичный подход к TDD делает основной упор на модульные тесты, потому что, считается, что они способны управлять дизайном кода (изначальное обоснование подхода «тесты вперед»).
Я не думаю, что это верно. Подход «тесты вперед» приводит к чрезмерно сложной структуре посреднических объектов и окольных путей, так как необходимо избежать «медленных» операций Например, обращений к базе данных. Или чтение-запись файла. Или запуска тестов в браузере, чтобы проверить всю систему. В итоге мы приходим к созданию монструозной архитектуры. Густые заросли служебных объектов, команд и чего похуже.
Я редко пишу юнит-тесты в традиционном смысле этого слова, где все зависимости мокаются, и тысячи тестов могут выполнены за несколько секунд. Это просто не было хорошим способом тестирования Rails приложений. Я тестирую модели Active Records напрямую, предоставляя доступ к реальной базе данных. Тесты работают на уровне контроллеров, но я бы пошел дальше и заменил бы эти тесты еще более высокоуровневыми тестами на Capybara.
Я думаю, что это то направление куда мы идем. Меньше внимания на юнит-тесты, потому что мы больше не используем подход «тесты вперед» как проектную практику и больше внимание на медленные системные тесты. (Которые, кстати, вовсе не обязательно должны быть медленными, за счет использования распараллеливания и облачной инфраструктуры).
Rails могут помочь с этим переходом. Сегодня мы ничего не делаем, чтобы поощрять полные системные тесты. У нас нет инструмента по умолчанию в стеке. Но мы собираемся исправить этот недостаток. Но не ждите, пока это произойдет. Попробуйте Capybara уже сегодня, и у вас будет хорошее представление о том, где мы окажемся завтра.
Но сначала сделайте глубокий вдох. Мы ведем наших священных коров на убой прямо сейчас. Это очень болезненно. Методология TDD настолько успешна, что теперь она вплетена в личности большого количества программистов. TDD не только то, что они делают, это, кто они. Мы проходим депрограммирование, чтобы выйти из-под контроля TDD, и это займет некоторое время.
Самое худшее, что мы можем сделать, это просто броситься в другую религию тестирования. Я легко могу себе представить золотого тельца «только системные тесты!» Пожалуйста, не делайте так.
Да, для меня подход «тесты вперед» мертв. Но вместо того, чтобы танцевать на его могиле, я предпочту признать огромный вклад TDD. TDD ознаменовала собой важный этап в нашей истории, но пришло время двигаться дальше.
Да здравствует тестирование.
Автор: GraDea
