Если я начинаю использовать TDD на проекте, который уже не использует его

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

Да.

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

, Возможно, рассматривают взглянуть на Разработка приложений Существующих производств в.NET ? Это полно прагматического и практического совета для точно этого сценария (одно из определений, предлагаемых для "Существующих производств", "без надлежащих модульных тестов").

Да, абсолютно хорошая идея начать делать TDD.

Вы оплатите стоимость запуска по крайней мере по двум причинам:

1. Осваивание нового навыка TDD/поблочное тестирование.
2. Модифицирование Вашего кода, чтобы быть тестируемым.

необходимо будет сделать некоторых из обоих, но поскольку Вы работаете, если Вы боретесь, думают, какой из тех двух является источником усилия.

, Но конечный результат стоит того. Из того, что Вы описываете, это - проект, с которым Вы намереваетесь жить долгое время. Помните это при потере часа здесь или там. Через год Вы будете очень рады, что сделали эти инвестиции и в Вашем наборе навыков и в кодовой базе.

В худшем можно просто сделать TDD на новом материале при медленном создании тестов для существующей кодовой базы.

Да, никогда не слишком поздно, чтобы начать использовать TDD. Я представил TDD коммерческому проекту, который уже работал в течение пяти лет, когда я присоединился, и это было определенно хорошее решение.

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

Для части кода, последний мог бы оказаться трудным, потому что код, который Вы записали до сих пор, вряд ли будет написан с тестируемостью в памяти. Существуют некоторые методы для контакта с этим, но, вероятно, слишком рано для заботы о них.

, Если Вы пропускаете умение ориентироваться, тем не менее, я сомневаюсь, что TDD поможет Вам много. Вы могли бы хотеть изучить Приемочные испытания вместо этого, которые, по крайней мере, так же важны как поблочное тестирование и помогут Вам сфокусироваться на функциональности системы вместо единых блоков кода. Книга TDD Lasse Koskela является хорошим введением в оба методы.

Другая техника, которая могла бы помочь Вам, является игрой планирования Экстремального программирования, куда Вы помещаете части функциональности на учетных карточках и располагаете по приоритетам их. Я обычно замечаю, что вытаскивание идей из моей головы и в расположенном по приоритетам порядке помогает мне много в понимании, где я хочу пойти затем.

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

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

Да.

TDD помогает другим людям понять код, а также он дает приложению лучший дизайн со временем

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

• Используют в своих интересах 80:20 правило, выполняют профилировщика и помещают тестовые сценарии в наиболее часто называемую часть кода.
• Помещенные тесты вокруг драгоценного камня дома, пищеварительного тракта, большинства - важный код.
• Помещенные тесты вокруг раздражающего, всегда повреждающегося, текущего dГ©jГ vu содержащий ошибки код.
• Помещенные тесты вокруг всех ошибок Вы производите впечатление прежде исправление ошибки для того, чтобы провалить тест.

Предупреждение: Помещение тестовых сценариев потребует рефакторинга, что означает, что необходимо зафиксировать что-то, что это не повреждает.

, Если бы Вы все еще любите модульные тесты в этой точке, Вы были бы Красными, Зелеными, Осуществив рефакторинг самостоятельно.

Абсолютно.

Представляют TDD новому коду и если время позволяет, представьте "Комментарий Управляемый Дизайн" с Вашим существующим кодом, если он уже не тестируется.

• Комментируют блок существующего кода, который необходимо протестировать
• Запись тест
• Некомментарий исходный код один оператор за один раз (если Вы имеете, если блок, не комментируют, весь блок)
• Определяют, проходит ли Ваш исходный код в конечном счете Ваш тест, и в противном случае перепишите, чтобы пройти Ваши тесты соответственно

Запись тестов для существующего, рабочего кода, который Вы не планируете изменить, не соответствует тяге TDD, который является к тесты записи, которые учат Вас системе, что Вы создаете.

Мой подход к введению середины реки TDD был к:

• тесты записи на все новые возможности, и
• при изменении части кода, пишут тест, который покрывает существующую функциональность (чтобы удостовериться, что я понимаю это), затем измените тест прежде, чем изменить код.

Это может также быть выгодно для тестов записи на код, связанный для кодирования, Вы изменяетесь - например, при изменении родительского класса можно хотеть создать тесты вокруг дочерних классов сначала для защиты себя от потенциального ущерба.