Не всегда получается продумать код хорошо с первого раза - каждый без труда вспомнит то чувство, когда в середине работы приходится менять только что написанный код из-за структурных проблем или плохого дизайна кода. Такие изменения неприятны, но все же проходят без заметного стресса.
При применении TDD не получится быстро поменять свежий код, если это меняет поведение юнита - придется править еще и тесты, а это двойная или даже тройная нагрузка, ведь нужно не только поправить код, но и тесты, да еще убедиться что и тесты и код все еще соответствуют требованиям задачи. И все из-за того что у нас есть тесты.
Из-за подобных сложностей может показаться, что практика TDD не оправдывает себя. На самом деле падающие тесты просто достают "пыль из-под ковра" и делают проблемы заметными. Ведь переделка свеженго кода без тестов - занятие тоже далеко не дешевое, но настолько привычное что мы не считаем это расходами, лишь увеличение стоимости этой операции позволяет увидеть реальную проблему.
Когда TDD помогает увидеть проблемы, у разработчика есть 2 варианта: бороться с проблемами пока их не останется или перестать использовать TDD, ошибочно посчитав, что TDD принесла проблемы а не вскрыла их. Вот только проблемы никуда не денутся, просто спрячутся под ковер до поры.