В общем возник такой вопрос - я наконец-то начал знакомиться с TDD и тут же начали появляться закономерные вопросы - а нужен ли он? и если нужен то в каких случаях?

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

Так же, какой величины проект должен быть, чтобы ефективно использовать TDD? Мне сейчас кажеться что из-за такой модели разработки проект затягивается по времени и архитектура выходит не очень привычная для меня (имелось ввиду, что использование к примеру разработоки с полным планированием архитектуры через юмд даст лучшую архитектуру) - я знаю что это ошибочное мнение, но не могу отделаться от такого чувства.

З.Ы. Задаю вопрос в .Net форуме потому что считаю что выбор платформы сильно влияет на выбор модели разработки, а в данном случае меня интересует только .Net

Это сообщение отредактировал(а) archeg - 5.5.2008, 13:18

Так же меня волнует еще вопрос по поводу имитирующих объектов. Во-первых, для их использования нужно добавлять лишние конструкторы, во-вторых, переходить на полностью интерфейсный метод работы. Не сильно ли плохо такое для архитектуры?

Как-то не приходилось. Насколько я могу судить, в большинстве мелких и средних проектов куда намного важнее скорость разработки, чем такая "перестраховка от ошибок" как TDD. Да и возрастающая сложность проекта играет роль при написании тестов - чем дальше в лес, тем труднее написать тест для сложной системы, охватывающий максимум вариантов использования. Раз при TDD тесты приходится писать заранее, то вообще непонятно как работать   

Ответил "Что такое TDD?", т.к. не сразу догадался что это разработка через тестирование.
C юнит-тестированием баловался, но в реальности TDD никогда не использовал - слишком муторно. Тест можно такой навернуть, что сложнее 
чем сам тестируемый объект будет.   

Хы... НУ вопрос конечно интересный... Когда я их использую:
1. Когда требует начальство.
2. Когда время на отладку почти не предоставится.
3. Новая технология.
4. Когда хочется сделать красиво. 
5. Когда в проекте ОЧЕНЬ сложная бизнес модель.
Когда не использую точно:
1. Когда требует начальство.
2. Когда проект очень ограничен во времени.
3. Уверен в себе. 
4. Когда уверен что красиво будет и так. 

В случаях не попадающих сюда, я чаще не использую PDD, чем использую... Почему? Ну ведь каждый программист ленив, если не лень, то использую, но это редко...  Что касается качества продукта, то оно конечно растет, и оспаривать это нельзя. Время при этом тоже растет, я бы сказал по экспоненте... 



Хм... Не понял я что вы имели ввиду. Если проектирование проекта удалось, то я думаю не сложно будет выделить модули, для которых требуется тестирование. 

Вообще никогда.





Еще не приходилось работать на проекте, где это бы оплачивалось.
Будут платить - буду использовать.

А если интересует нравится эта фича - или нет... Нет, не нравится. 
Дисскутировать на религиозные темы хочется, поэтому не буду описывать почему   

tol05, согласен.   

Бывают всякие мега-подходы и гига-технологии, которые поначалу жутко модные (например extreme programming), а потом как-то подзабываются комьюнити и становятся неактуальными. И тем более не оплачиваются   

У меня на одном проекте на С++ использовалось TDD. Проект был не маленький: пара тысяч классов и  около миллиона строк кода, с постоянно меняющимися требованиями к бизнес-логике. В определенный момент решили отказаться от него, т.к. урезали количество разработчиков на проекте. И только потом реально поняли, что c TDD у нас разработка шла бы быстрее.  
В малых проектах и в проектах без постоянно меняющейся логики использовать TDD я считаю неэффективно. 
А вот в проектах с постоянно меняющейся бизнес-логикой TDD просто спасение.