Из прочтения описаний я понимаю, что в TDD тесты выполняются до написания функции, а в модульном тестировании - после.
Является ли это основным отличием, или эти два термина даже нельзя сравнивать как таковые? Возможно, Unit Testing является неотъемлемой частью TDD.
Ответы:
Модульное тестирование относится к то , что вы проверяете, TDD в при тестировании.
Два ортогональны.
Модульное тестирование означает, ну, тестирование отдельных единиц поведения. Индивидуальная единица поведения - это наименьшая возможная единица поведения, которая может быть индивидуально проверена изолированно. (Я знаю, что эти два определения являются круглыми, но на практике они, похоже, хорошо работают.)
Вы можете написать модульные тесты до того, как напишите свой код, после того, как вы напишите свой код или пока вы пишете свой код.
TDD означает (опять-таки, очевидно), что позволить вашим тестам управлять вашей разработкой (и вашим дизайном). Вы можете сделать это с помощью модульных, функциональных и приемочных испытаний. Обычно вы используете все три.
Наиболее важной частью TDD является серединой D . Вы позволяете тестам управлять вами. Тесты говорят вам, что делать, что делать дальше, когда вы закончите. Они говорят вам, что API будет, каков дизайн. (Это важно: TDD не предназначен для написания тестов в первую очередь. Существует множество проектов, которые сначала пишут тесты, но не практикуют TDD. Сначала писать тесты - это просто предпосылка, позволяющая тестам управлять разработкой.)
Вы можете проводить модульное тестирование, не занимаясь разработкой, управляемой тестами. Однако вы не можете сделать разработку через тестирование без использования модульных тестов.
Когда вы выполняете традиционное модульное тестирование , вы пишете test после того, как написали свой код.
Тест разработки на основе подхода является написание модульного тестирования , прежде чем писать код.
Наиболее интересные преимущества TDD (IMHO) по сравнению с простым модульным тестированием:
TDD и модульное тестирование - это два очень специфических термина, которые часто неправильно используются.
TDD пишет тест, который не пройдёт, затем пишет минимальное количество кода, необходимого для его запуска, и затем реорганизует код, чтобы сделать его чистым. Это делается циклически, сбой -> проход -> рефакторинг, добавляя новый тест для каждого известного требования к коду. Совсем недавно TDD стал еще более конкретно относиться к написанию модульных тестов в этом цикле, чтобы отличать его от ATDD (подмножество BDD), которое пишет приемочные тесты в аналогичном цикле.
Модульное тестирование - это тестирование кода небольшими изолированными модулями. Распространенная путаница заключается в том, что если вы используете инструмент модульного тестирования, такой как xUnit или Rspec, для запуска тестов, то вы пишете модульные тесты. Это не обязательно правда. Эти инструменты можно использовать для запуска, скажем, тестов с использованием инфраструктуры Selenium - в этом случае вы пишете приемочные тесты с использованием модуля модульных тестов. Модульные тесты - это очень специфичные тесты, которые фокусируются на небольшом фрагменте логики, изолированном от всего остального ради скорости (чтобы вы могли часто их запускать и быстро получать отзывы о новых ошибках).
TDD - это подход написания тестовых примеров перед разработкой, как вы сказали, а затем разработчик пишет код для прохождения тестовых случаев. Модульное тестирование - это термин, используемый для описания узкоспециализированного типа тестирования, отличного от тестирования системы, интеграционного тестирования и приемочного тестирования.
То, как я разделяю их, состоит в том, чтобы учесть, что TDD - это не столько тестирование, сколько разработка кода. Затем используются модульные тесты, чтобы установить ожидания для кода конца. Когда код завершения написан и проходит тесты (спецификации), у вас есть код, который был разработан с использованием тестов.
Все отличные ответы. Я только добавил бы, что модульное тестирование имеет тенденцию рассматривать «модуль» как небольшой компонент, в то время как TDD расширяется, чтобы включать интеграционные и приемочные тесты.
(Некоторые варианты TDD рассматривают «устройство» как наименьший шаг в направлении желаемой функциональности ...)