TDD это забавный зверек пригодный для расчетных задач. Но в большинстве случаев мы пишем что-то работающее с пользовательскими интерфейсами, а для этого чрезвычайно сложно создать автоматический тест. Поэтому и TDD распространения не получил.
Но если у тебя задача типа взять один файл и превратить его в другой - то TDD становится чрезвычайно удобным. Можно даже утверждать что для любых конверторов TDD это наиболее естественный процесс разработки.
Но для любых приложений с GUI это уже практически неприменимо.

kmawВаш ответ скорее против, чем за TDD, как мне кажется. меня больше интересует, как этот TDD, работает в обычных бизнес-приложениях. там все уже известно - что и как. а бизнес логика - именно то что есть "бизнес-логика" - та часть, которую надо неизбежно говнокодитьха-ха-ха.
Во впервых, кому нужно? Бизнес покупает готовый продукт (1С хотя бы) и подтягивает свою бизнес-логику под нее.
Разработки с нуля обычно начинаются там где бизнес-логикой и не пахнет. У них весь бизнес процесс на уровне "здесь играть, здесь не играть, здесь рыбу заворачивали". И когда такой бизнес решается на автоматизацию то жесткие рамки готовых решений не годятся и начинается своя разработка. Но под нее написать тесты практически нереально (смотри описание бизнес-логики).
Ну и во вторых, бизнес-приложения это всегда в первую очередь GUI клиенты для офисного люда. А для GUI тесты делать сложно.

У TDD расшифровка какая? Test Driven Development - уже из названия видно, что тесты стоят во главе всего. Если ты можешь написать автоматизированные тесты для всех частей своего приложения, то TDD будет хорошим выбором. А если с тестами напряг - то и опаньки.