Почему TDD дается сложно инженерам?

Полезно изучать несколько тем параллельно, ведь как раз на пересечении и рождаются самые интересные открытия. 

Три недели назад я публиковал пост на FB о критерии фальсифицироемости с научно-популярным объяснением от Veritasium. Пару дней назад мы обсуждали с коллегой старый добрый TDD подход. А на утро следующего дня повторяя эту чудную загадку от Veritafium в разговоре с другим коллегой, бам - инсайт. 

Проведи эксперимент над друзьями. Предложи раскрыть задуманную тобой закономерность, сообщать о которой ты можешь только отвечая true / false на три числа, которые по мнению отгадывающего должны соответствовать этой закономерности. В качестве вводной ты называешь 2, 4, 8 и говоришь, что эти числа соответствуют задуманной тобой закономерности. Дальше отгадывающий должен подумать и если у него есть идея что это за закономерность - предложить три числа, которые соответствуют ей. С него три числа, а с тебя true или false. Дальше на оригинальном видео (можно включить русские субтитры)

Что получается, большинство людей придумав гипотезу, сразу же стараются ее доказать. Видимо в этом by default поведении была какая-то потребность в процессе эволюционного развития мозга (а может и сейчас есть). Но такой подход приводит людей часто ко всяким лженаукам. Так гипотеза очень быстро превращается в теорию, если доказывать только ее правдивость или вскоре принять на веру. 

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

"Принцип фальсифицируемости противоположен принципу верифицируемости. При верификации гипотезы исследователь ищет подтверждающие её примеры, при фальсификации — примеры, опровергающие её." (с) Википедия

Чтобы все было по-научному, надо как минимум чтобы то что тобой придумано могло быть опровержимым экспериментально (или как-нибудь еще). То что очень большое число фактов подтверждает твою идею о том, как устроен мир, делает ее весьма вероятной, но не на 100% достверной. Достаточно всего лишь 1 опровергаюего факта, чтобы идею можно было отклонить как ложную. А вот это уже неприятно. Ведь то, что придумалось мной, такое мое, такое "правильное", а все кто не согласен с этим просто глупые, чтобы понять это. Так и носимся с идеей, как курица с яйцом. А могли бы откинуть сразу и заняться поисками чего-то по-настоящему рабочего. 

TDD как раз заставляет относиться к своему коду (твоей гипотезе, которая описывает желаемый заказчиком результат) как к чему-то скорее всего неполному и требующему доработки (недоделанные кейзы, ошибки в понимании ТЗ, ошибки в реализации, ошибки интеграции и т.д.). Ты пишешь тест, чтобы найти опровержение тому, что код работает. Тест красный - поздравляю, у тебя появился шанс улучшить реализацию. Если не можешь найти очередной красный тест - вероятно ты сильно приблизился к завершению. Сделай перерыв и попобуй после. 

Намного проще (по классике) написать быстро функционал и сделать 3-4 теста, подтверждающих что все-все работает. Именно так bu default мыслит наш мозг, и тесты будут зеленые. Только не факт что они вообше что-то проверяют. А если и проверяют, то всего лишь верифицируют твою гипотезу о том, как должен работать код, а надо гипотезу фальсифицировать. 

Кент Бек ввел критерий фальсифицируемости (критерий Поппера) в мир программирования из мира науки. Тот фильтр восприятия, благодаря которому можно больше и быстрее находить ошибки в умозаключениях. Такие частые...

С TDD Кент Бек привносит в кодирование научный подход. 

Бам!