Давайте процитирую ещё одного умного человека

http://www.thalion.kiev.ua/idx.php/17/351/article/

TDD — это не самоцель

Тесты — это не вещь в себе. Но часто разработчики впадают в крайность — это ситуация, когда тестам начинают уделять повышенное внимание. Разработчики пишут слишком много тестов, проверяют все и вся. И это однажды перерастает в разработку ориентированную на тесты (testing oriented development anti-pattern). Джемс Гринвуд так описывает этот анти-паттерн: «Когда неопытные или введенные в заблуждение программисты продолжают писать тесты, хотя в этом нет никакого смысла с практической или финансовой точки зрения. При этом они думают, что это и есть TDD и, добавляя в систему все новые и новые тесты, они увеличивают ее стоимость». Думается, что комментировать это определение нет смысла.

Попробую описать другой случай, когда тесты становятся самоцелью и мешают развитию проекта. Иногда это связывают с запахом «Чрезвычайное упования на мок-объекты», но иногда причина кроется в другом. Мы сталкивались с данной проблемой достаточно давно, но последствия дают о себе знать до сих пор. Суть ее такова: у нас был код, который очень трудно поддавался тестированию, так как он не был создан с учетом test-ability. Но, не понимая сути TDD, мы вместо того, чтобы искать причины в дизайне системы, делали все возможное, чтобы просто написать тесты. В результате мы получили полный хаос с частичными или полными мок-объектами, методами вида doParentSomething(), непонятными и огромными фикстурами. То есть мы плодили ненужный код, который тоже нужно было поддерживать. При этом тесты являлись дополнительным фактором загнивания проекта, так как они были очень хрупкими, хотя по идее они должны были напротив повышать его гибкость и качество. Лишь намного позже мы поняли, что тесты наглядно нам показывали, что у нас есть большие проблемы c дизайном рабочего кода. Хороший рабочий код не должен иметь сложных тестов! Это показатель того, что архитектура имеет серьезные недостатки. После правильного применения техник снижения зависимостей между классами, тесты значительно упростились, и их поддержка теперь не составляет труда.

Об ошибках, связанные с написанием слишком большого количества тестов до рабочего кода мы указывали ранее. Никакого реального преимущества тесты в этом случае также не дают, а становятся вещью в себе.

TDD – это прежде всего design activity, то есть деятельность направленная на формирование дизайна системы. Тесты выступают в качестве примеров реального использования кода и именно в этом их одна из основных ценностей. Досконально проверять рабочий код при помощи тестов — это слишком дорого. Тесты должны помогать в разработке, делать ее более предсказуемой и управляемой, а не трудоемкой и нудной. В конце концов, они должны позволить нам зарабатывать больше денег, делать свою работу быстрее и лучше.

Выводы

Разработка через тестирование для меня была чем-то вроде серебряной пули, решением всех проблем. Я готов был с горящими глазами доказывать, что тесты — панацея от всех бед, что нужно всем скорее начинать практику написания тестов. Теперь пришло небольшое прозрение. Сейчас я понимаю, что это всего лишь инструмент, а то, как этот инструмент используется, зависит от человека, который это инструмент держит в руках. В чьих-то руках он может приносить много пользы, а в других — много вреда. Если вам нравится все то, что сулит TDD, то будьте готовы к жертвам: это и потеря скорости разработки в первое время, и жесткая дисциплина и самоконтроль, интенсивное обучение и т.д. Все эти жертвы потом с лихвой окупятся. Многие же не выдерживают и возвращаются к прежнему стилю работы. Но, по нашему мнению, а также по мнению некоторых знакомых нам TDD-практиков, как только разработчик почувствовал зависимость от «зеленой полосы», узнал, что такое полный контроль за кодом, то есть стал инфицированным тестами (test-infected), он уже никогда не откажется от тестирования. Пока никто из наших знакомых не жалеет времени, потраченного на изучение и эксперименты с TDD. Я очень надеюсь, что эта статья поможет кому-то ускорить внедрение TDD и избежать тех ошибок, которые мы допускали.

P.S. Сравните с http://programmingmindstream.blogspot.ru/2013/11/tdd_28.html