Test Driven Design - где я ошибся?

Question

Я играю с игрушечным проектом дома, чтобы лучше понять Test Driven Design.Сначала казалось, что все идет хорошо, и я попал в зону неудачных тестов, кода, прохождения теста.

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

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

Такое ощущение, что я сошел с трассы TDD.Что, по-твоему, я сделал неправильно?

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

Answer 1

Возможно, вы пошли слишком быстро, разбив свой класс. Шаги для Извлечения класса извлечения следующие:

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

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

Также убедитесь, что вы тестируете поведение, а не реализацию .

Answer 2

Я хотел прокомментировать принятый ответ, но моя текущая репутация не позволяет мне. Так что вот как новый ответ.

TDD говорит:

Создать тест, который не проходит. Код немного. Пройдите тест.

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

Answer 3

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

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

Answer 4

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

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

http://www.hardcoded.net/articles/high-level-testing.htm

Удачи с TDD, пока не сдавайтесь.

Answer 5

Единственное «неправильно» было добавить тест после этого. В «истинном» TTD вы сначала объявляете все тесты до фактической реализации. Я говорю «правда», потому что это часто только теория. Но на практике у вас все еще есть безопасность, которую дают тесты.

Answer 6

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

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