Разница между модульным тестированием и разработкой на основе тестирования

64

Из прочтения описаний я понимаю, что в TDD тесты выполняются до написания функции, а в модульном тестировании - после.

Является ли это основным отличием, или эти два термина даже нельзя сравнивать как таковые? Возможно, Unit Testing является неотъемлемой частью TDD.

unit-testing tdd difference Шамим Хафиз
источник

Ответы:

104

Модульное тестирование относится к то , что вы проверяете, TDD в при тестировании.

Два ортогональны.

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

Вы можете написать модульные тесты до того, как напишите свой код, после того, как вы напишите свой код или пока вы пишете свой код.

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

Наиболее важной частью TDD является серединой D . Вы позволяете тестам управлять вами. Тесты говорят вам, что делать, что делать дальше, когда вы закончите. Они говорят вам, что API будет, каков дизайн. (Это важно: TDD не предназначен для написания тестов в первую очередь. Существует множество проектов, которые сначала пишут тесты, но не практикуют TDD. Сначала писать тесты - это просто предпосылка, позволяющая тестам управлять разработкой.)

Йорг Миттаг
источник
1
Отличный ответ. добавил бы ... TDD - это когда вы позволяете тестам подталкивать вас к своим возможностям и усилиям по разработке ...
Мартин,
Они не ортогональны, хотя. Вы не можете иметь TDD без юнит-тестов.
JacquesB
1
@JacquesB, почему? Наши тесты - это не то, что вы бы назвали модульными тестами по любому определению, они слишком сильно зависят от инфраструктуры и других компонентов, но у нас все еще достаточно наблюдательности, чтобы мы - ну, по крайней мере, некоторые из нас - делали TDD.
AProgrammer
3
@AndrewWillems: TDD означает, что тесты определяют развитие . Тесты говорят, что вы не решаете, как выглядит дизайн. Вы не решаете, над чем работать дальше, тесты говорят вам. Вы не решаете, когда закончите, тесты говорят вам. Вполне возможно сначала написать тесты, а затем игнорировать все, что они вам говорят. Например, вы можете сначала написать тесты, но затем продолжать писать код даже после того, как все тесты будут зелеными. Итак, другими словами: сначала вы пишете тесты, но относитесь к ним как к тестам и не позволяете им управлять разработкой.
Йорг Миттаг
1
@ JörgWMittag Вы можете быть правы, если смотреть на это по-пуристски, но вы также знаете, что TDD не черно-белый. Любое вменяемое использование TDD не позволило бы тестам полностью управлять разработкой, и тесты определенно не всегда решают, как выглядит дизайн (возможно, модульные тесты могут сделать это частично, но не тесты на более высоком уровне абстракции). Как насчет рефакторинга? Что является очень важным аспектом TDD. Также в реальном мире не существует такой вещи, как «игнорировать все, что говорит вам тест». По определению, если вы сначала пишете тесты, вы используете «некоторую форму TDD».
Ник
21

Модульное тестирование является компонентом Test Driven Development

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

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

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

Наиболее интересные преимущества TDD (IMHO) по сравнению с простым модульным тестированием:

  • Код полностью протестирован. Это безболезненное тестирование.
  • Это заставляет вас правильно оформлять свои классы.
  • Это также заставляет вас держать это просто глупо .
  • Цикл Red-Green-Refactor - абсолютный убийца прокрастинации!

источник
Вы пропустили «единицу» специально в формулировке: «Однако вы не можете сделать разработку через тестирование без использования тестирования». ?
Раткок
@ratkok: нет, это не было специально. Позвольте мне это исправить.
Мне нравится это определение лучше всего. Лучше собрать словами, чем другими ответами.
Tek
2
Возможно, вы можете сделать TDD, используя модульные тесты или системные тесты, а не настоящие юнит-тесты. Я бы не советовал, поскольку вы теряете большую часть пользы, если тесты выполняются слишком долго, но это не невозможно.
Тоби Спейт
13

TDD и модульное тестирование - это два очень специфических термина, которые часто неправильно используются.

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

Модульное тестирование - это тестирование кода небольшими изолированными модулями. Распространенная путаница заключается в том, что если вы используете инструмент модульного тестирования, такой как xUnit или Rspec, для запуска тестов, то вы пишете модульные тесты. Это не обязательно правда. Эти инструменты можно использовать для запуска, скажем, тестов с использованием инфраструктуры Selenium - в этом случае вы пишете приемочные тесты с использованием модуля модульных тестов. Модульные тесты - это очень специфичные тесты, которые фокусируются на небольшом фрагменте логики, изолированном от всего остального ради скорости (чтобы вы могли часто их запускать и быстро получать отзывы о новых ошибках).

прецизионный самописец
источник
1
Хороший пример - тесты JUnit для самого JUnit: значительная их часть - функциональные тесты и приемочные тесты, а не модульные тесты, даже если они написаны на JUnit. Также создатель JUnit также является создателем TDD, а JUnit был разработан с использованием TDD с использованием значительного количества функциональных и приемочных тестов. Приемочное тестирование является неотъемлемой частью TDD.
Йорг Миттаг
6

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

M.Sameer
источник
3

TDD - это философский подход к написанию кода: сначала пишите тесты. Тесты, которые вы пишете, являются юнит-тестами.

Tangurena
источник
1

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

Грант Пэйлин
источник
1

Все отличные ответы. Я только добавил бы, что модульное тестирование имеет тенденцию рассматривать «модуль» как небольшой компонент, в то время как TDD расширяется, чтобы включать интеграционные и приемочные тесты.

(Некоторые варианты TDD рассматривают «устройство» как наименьший шаг в направлении желаемой функциональности ...)

Стивен А. Лоу
источник
они должны, но по моему опыту в действительности они не делают. Компании / группы говорят, что они проводят TDD, когда все, что они делают, - это заставляют программистов сначала тестировать тесты jUnit, а затем использовать тот факт, что все уже было протестировано в ходе разработки, чтобы отказаться (или значительно сократить) тестирование качества и интеграционное тестирование.
jwenting
1
@jwenting не винит методологию за недостатки тех, кто утверждает, что практикует это. любой инструмент может быть использован не по назначению
Стивен А. Лоу
1
Я не знаю, но вы должны понимать, что есть большая разница между тем, что TDD в теории, и тем, чем оно является на самом деле. И поскольку большинство людей (включая ОП), вероятно, только когда-либо видят реальность, им следует указать на разницу.
jwenting
Учитывая, что TDD - это проектирование, зачем включать приемочные испытания? как бы это "управлять" дизайном?
Виталий Исаенко
Приемочные тесты @VitaliiIsaenko обеспечивают определение объема работ на высшем уровне
Стивен А. Лоу