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

Ваш ответ скорее против, чем за TDD, как мне кажется. меня больше интересует, как этот TDD, работает в обычных бизнес-приложениях. там все уже известно - что и как. а бизнес логика - именно то что есть "бизнес-логика" - та часть, которую надо неизбежно говнокодить - как тут это TDD имеет место быть? часто пишут в интернетах: вот контроллер, вот репозиторий. но это как-то мимо всев обычных бизнес-приложениях работает BDD

egorychДохтаРЯ прошу прощения , но последние бестпрактисы
гласят что мухи ( гуй ) отдельно , а котлеты ( бизнеслогика ) отдельно.это не бестпрактикс, это идеи теоретиков.
"если текущая дата превышает ожидаемую дату оплаты, то строку поставки необходимо выделить красным цветом" - как тебе такой кейс? и таких кейсов - миллион, и все они - бизнес-логика в гуе.Перевести на Gherkin и реализовать тест.

http://rsdn.ru/article/testing/WebTest.xml

F#egorychпропущено...



Раскрашиваение по условию вполне тестируется модульным тесто модели представления.используя Jasmine например

F#Есть интересная книжка How Google tests software - там можно почитать, как они тестируют хром. Причем именно рендеринг страничек. Так что UI тоже поддается автоматизации.+1 за книжку :)