Может ли Test-Driven разработка работать в унаследованных проектах?

Итак, вот вопрос к вам, прочитав несколько отличных ответов на такие вопросы, как Test-Driven Development - Convince Me .

Итак, мой вопрос: "Может ли Test-Driven Development быть эффективно использована на не Greenfield проектах?".

С какими проблемами может столкнуться программист, если он попытается использовать TDD в проекте, в котором уже присутствуют элементы, не относящиеся к TDD?

1. Прочтите статью Эффективная работа с устаревшим кодом

   http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

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

2. Признайте, что TDD не означает буквально «все тесты перед всем кодом». Наличие кучи кода без теста не полностью нарушает модель TDD. Это немного усложняет задачу, но это все еще может быть TDD, даже если на данный момент отсутствуют модульные тесты.

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

4. Напишите один тест для одной вещи, которая находится в разработке.

5. Заставьте этот единственный тест работать.

Повторите шаги 3, 4 и 5 для каждого результата, который у вас есть. Вы делаете TDD только для новой разработки. Наследие осталось как было.

Иногда вы переписываете, пересматриваете или расширяете устаревший код.

Кроме того, когда вы занимаетесь обслуживанием и исправлением ошибок, вы будете делать несколько иные вещи.

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

2. Теперь, когда код, который вы собираетесь изменить, структурирован, его можно протестировать. Теперь вы можете (а) запускать тесты на устаревшей версии, (б) пересматривать тесты, (в) пересматривать код, (г) запускать тесты в исправленной версии.

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

Когда вы диагностируете проблему с устаревшим кодом, вы также можете использовать тесты, чтобы облегчить диагностику.

1. Перепишите отчет об ошибке в тестовый пример.

2. При необходимости отрефакторьте вероятные виновные модули для тестирования. Они могут быть не предназначены для модульного тестирования, что затрудняет использование TDD.

3. После рефакторинга у вас есть модульный тест, демонстрирующий ошибку. Запустить его. Это должно потерпеть неудачу. Теперь вы делаете TDD. У вас есть тест и код, который не проходит тест.

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

Цель состоит в том, чтобы изолировать функциональность с помощью «внедрения зависимостей» (шаблоны проектирования делегирования или стратегии) ​​и фиктивных объектов.

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

  Некоторые программисты возражают против этого, потому что тестируемый API часто «слишком много раскрывает» или требует «слишком много строк кода от клиента» или какое-то другое нытье. Это не были меры качества. Тестирование имеет большую ценность, чем код-гольф. Несколько дополнительных строк инициализации в рабочем приложении никого не убьют. Несколько дополнительных строк инициализации для облегчения тестирования могут в долгосрочной перспективе сэкономить массу усилий по диагностике и обслуживанию.

• Создание макетов — на некоторых языках — это вид искусства. Для этого есть библиотеки и фреймворки. Языки со статическими объявлениями типов (Java, C#, C++ и т. д.) требуют сложных моков. Языки с утиной типизацией (Python, Ruby и т. д.) не требуют причудливых фиктивных библиотек.