Модульные тесты в TDD

Question

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

Answer 1

Краткое описание TDD, выраженное в трех правилах :

1. Запрещается написание какого-либо производственного кода, если только он не прошел неудачный тестовый блок.
2. Вам не разрешено писать больше модульных тестов, чем достаточно, чтобы провалиться;и ошибки компиляции - это ошибки.
3. Вы не можете писать больше производственного кода, чем достаточно для прохождения одного неудачного модульного теста.

И более подробное описание: http://jamesshore.com/Agile-Book/test_driven_development.html

И более подробное описание: http://www.growing -object-oriented-software.com /

Answer 2

Просто наблюдение - ты сказал

Я заметил, что модульное тестирование занимает много времени

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

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

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

Answer 3

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

следует применять юнит-тесты к каждому разработанный компонент

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

Answer 4

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

Хорошее эссе о TDD доступно здесь