| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Общие вопросы по .NET и C# > TDD в .Net |
| Автор: archeg 5.5.2008, 13:16 |
| В общем возник такой вопрос - я наконец-то начал знакомиться с TDD и тут же начали появляться закономерные вопросы - а нужен ли он? и если нужен то в каких случаях? Подчеркну - имеется ввиду именно TDD а не любая модель разработки в которой используються тесты. Очень хотелось бы услышать обоснованые ответы - если вы используете не всегда, то в каких случаях на ваше мнение нужно, а в каких не стоит? Так же, какой величины проект должен быть, чтобы ефективно использовать TDD? Мне сейчас кажеться что из-за такой модели разработки проект затягивается по времени и архитектура выходит не очень привычная для меня (имелось ввиду, что использование к примеру разработоки с полным планированием архитектуры через юмд даст лучшую архитектуру) - я знаю что это ошибочное мнение, но не могу отделаться от такого чувства. З.Ы. Задаю вопрос в .Net форуме потому что считаю что выбор платформы сильно влияет на выбор модели разработки, а в данном случае меня интересует только .Net |
| Автор: archeg 5.5.2008, 13:53 |
| Так же меня волнует еще вопрос по поводу имитирующих объектов. Во-первых, для их использования нужно добавлять лишние конструкторы, во-вторых, переходить на полностью интерфейсный метод работы. Не сильно ли плохо такое для архитектуры? |
| Автор: mr.DUDA 5.5.2008, 16:03 |
| Как-то не приходилось. Насколько я могу судить, в большинстве мелких и средних проектов куда намного важнее скорость разработки, чем такая "перестраховка от ошибок" как TDD. Да и возрастающая сложность проекта играет роль при написании тестов - чем дальше в лес, тем труднее написать тест для сложной системы, охватывающий максимум вариантов использования. Раз при TDD тесты приходится писать заранее, то вообще непонятно как работать |
| Автор: Ch0bits 5.5.2008, 21:33 |
| Ответил "Что такое TDD?", т.к. не сразу догадался что это разработка через тестирование. C юнит-тестированием баловался, но в реальности TDD никогда не использовал - слишком муторно. Тест можно такой навернуть, что сложнее чем сам тестируемый объект будет.  |
| Автор: Veitmen 6.5.2008, 13:29 | ||
| Хы... НУ вопрос конечно интересный... Когда я их использую: 1. Когда требует начальство. 2. Когда время на отладку почти не предоставится. 3. Новая технология. 4. Когда хочется сделать красиво.  5. Когда в проекте ОЧЕНЬ сложная бизнес модель. Когда не использую точно: 1. Когда требует начальство. 2. Когда проект очень ограничен во времени. 3. Уверен в себе. 4. Когда уверен что красиво будет и так. В случаях не попадающих сюда, я чаще не использую PDD, чем использую... Почему? Ну ведь каждый программист ленив, если не лень, то использую, но это редко... Что касается качества продукта, то оно конечно растет, и оспаривать это нельзя. Время при этом тоже растет, я бы сказал по экспоненте...
Хм... Не понял я что вы имели ввиду. Если проектирование проекта удалось, то я думаю не сложно будет выделить модули, для которых требуется тестирование. |
| Автор: tol05 6.5.2008, 17:29 |
| Вообще никогда. Еще не приходилось работать на проекте, где это бы оплачивалось. Будут платить - буду использовать. А если интересует нравится эта фича - или нет... Нет, не нравится. Дисскутировать на религиозные темы хочется, поэтому не буду описывать почему  |
| Автор: mr.DUDA 6.5.2008, 17:42 |
tol05, согласен.  Бывают всякие мега-подходы и гига-технологии, которые поначалу жутко модные (например extreme programming), а потом как-то подзабываются комьюнити и становятся неактуальными. И тем более не оплачиваются  |
| Автор: Gelis 7.5.2008, 17:05 |
| У меня на одном проекте на С++ использовалось TDD. Проект был не маленький: пара тысяч классов и около миллиона строк кода, с постоянно меняющимися требованиями к бизнес-логике. В определенный момент решили отказаться от него, т.к. урезали количество разработчиков на проекте. И только потом реально поняли, что c TDD у нас разработка шла бы быстрее. В малых проектах и в проектах без постоянно меняющейся логики использовать TDD я считаю неэффективно. А вот в проектах с постоянно меняющейся бизнес-логикой TDD просто спасение. |