Різниця між тестуванням одиниць та розробкою тестового керування


64

Читаючи описи, я розумію, що тести TDD робляться до написання функції, а в Unit Testing - після цього.

Це головна відмінність, або два терміни навіть не можна порівняти як такі. Можливо, Unit Testing є складовою частиною TDD.

Відповіді:


104

Модульне тестування відноситься до то , що ви перевіряєте, TDD в при тестуванні.

Два є ортогональними.

Тестування одиниць означає, що добре, тестування окремих одиниць поведінки. Індивідуальна одиниця поведінки - це найменша можлива одиниця поведінки, яку можна індивідуально випробувати окремо. (Я знаю, що ці два визначення кругові, але вони, схоже, спрацьовують на практиці.)

Ви можете писати одиничні тести перед тим, як писати свій код, після того як ви пишете свій код або поки ви пишете свій код.

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

Найбільш важливою частиною TDD є серединою D . Ви дозволяєте тестам керувати вами. Тести показують, що вам робити, що робити далі, коли закінчите. Вони розповідають, яким буде API, яким є дизайн. (Це важливо: TDD - це не про те, щоб спершу писати тести. Існує безліч проектів, які спочатку пишуть тести, але не практикують TDD. Спочатку написання тестів - просто необхідна умова для того, щоб тести могли рухати розробку.)


1
Чудова відповідь. додамо ... TDD - це коли ви дозволяєте тестувати вас, і функції, щоб підтягнути ваші зусилля з розвитку ...
Мартін

Вони не ортогональні. Ви не можете мати TDD без тестових одиниць.
ЖакБ

1
@JacquesB, чому? Наші тести - це не те, що ви б називали одиничними тестами за будь-яким визначенням, вони занадто сильно залежать від інфраструктури та інших компонентів, але у нас все ще достатньо спостережливості, щоб ми - ну принаймні деякі з нас - займалися TDD.
AProgrammer

3
@AndrewWillems: TDD означає, що тести керують розробкою . Ви не вирішуєте, як виглядає дизайн, підказують тести. Ви не вирішите, над чим працювати далі, підкажуть тести. Ви не вирішите, коли закінчите, тести вам скажуть. Цілком можливо спершу написати тести, а потім ігнорувати все, що вони тобі кажуть. Наприклад, ви можете написати тести спочатку, але потім продовжуйте писати код навіть після того, як всі тести будуть зеленими. Отже, іншими словами: ви спершу пишете тести, але ви ставитесь до них як до тестів, і не дозволяйте їм рухати розробку.
Йорг W Міттаг

1
@ JörgWMittag Можливо, ви маєте рацію на пуристський погляд на це, але ви також знаєте, що TDD не є чорно-білим. Будь-яке розумне використання TDD не дозволить тестам керувати розробкою повністю, і тести, безумовно, не завжди вирішують, як виглядає конструкція (можливо, одиничні тести можуть частково це зробити, але не тести на більш високому рівні абстракції). А як щодо рефакторингу? Це дуже важливий аспект TDD. Також у реальному світі немає такого поняття, як "ігноруйте все, що вам каже тест". За визначенням, якщо ви спочатку пишете тести, ви використовуєте "певну форму TDD".
NickL

21

Тестування блоку є складовою тестової розробки

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

Коли ви робите традиційне тестування одиниць , ви пишете тест після написання коду.

Тестовий підхід до розробки полягає в написанні одиничного тесту перед написанням коду.

Найцікавіші переваги TDD (IMHO) порівняно з простим модульним тестуванням:

  • Код є повністю перевіреним кодом заздалегідь. Це безболісне тестування.
  • Це змушує правильно складати свої класи.
  • Це також змушує вас робити це просто дурним .
  • Цикл Червоного-Зеленого-Рефактора - абсолютний вбивця зволікання!

Ви пропустили цілеспрямовано "одиницю" у статті: "Однак ви не можете робити тестові розробки без використання тестування." ?
ratkok

@ratkok: ні, це не було навмисно. Дозвольте це виправити.

Мені подобається це визначення найкраще. Краще зібрати слова, ніж інші відповіді.
Тек

2
Можливо, ви можете робити TDD, використовуючи модульні тести або системні тести, а не справжні одиничні тести. Я б не радив цього, оскільки ви втратите велику користь, якщо тести займуть занадто довго, але це неможливо.
Toby Speight

13

TDD і Unit Testing - це два дуже конкретні терміни, які часто не вживаються.

TDD пише тест, який не вдасться, потім записує мінімальну кількість коду, необхідного для його запуску, потім рефакторинг коду для очищення. Це робиться циклами, відмов -> pass -> refactor, додаючи новий тест для кожної відомої вимоги до коду. Зовсім недавно TDD став ще більш конкретно щодо написання одиничних тестів у цьому циклі, щоб відрізнити його від ATDD (підмножина BDD), яка пише тести прийняття в аналогічному циклі.

Тестування одиниць - це тестування коду в малих ізольованих одиницях. Загальна плутанина тут полягає в тому, що якщо ви використовуєте інструмент тестування одиниць, наприклад xUnit або Rspec, для запуску тестів, які ви пишете одиничними тестами. Це не обов'язково правда. Ці інструменти можуть бути використані для запуску тестів сказати, використовуючи рамки Selenium - у цьому випадку ви пишете приймальні тести, використовуючи модуль тестування блоку. Блокові тести - це спеціально тести, які зосереджуються на невеликій логіці, виділеній від усього іншого задля швидкості (так що ви можете запускати їх часто і отримувати швидкий відгук про нові помилки).


1
Самі тести JUnit для JUnit є хорошим прикладом: значна частина - це функціональні тести та приймальні тести, а не одиничні тести, хоча вони написані в JUnit. Також творець JUnit також є творцем TDD, а JUnit був розроблений за допомогою TDD, використовуючи значну кількість функціональних тестів та тестів прийняття. Тестування на прийняття є невід'ємною частиною TDD.
Йорг W Міттаг

6

TDD - це підхід до написання тестових випадків до розробки, як ви вже говорили, і тоді розробник пише код для передачі тестових випадків. Unit Testing - термін, що використовується для опису вузького діапазону випробувань, окрім тестування системи, інтеграційного тестування та тестування приймання.


3

TDD - філософський підхід до написання коду: спочатку напишіть тести. Тести, які ви пишете, є одиничними тестами.


1

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


1

Усі відмінні відповіді. Я хотів би лише додати, що тестування приладів, як правило, розглядає «одиницю» як невелику складову, тоді як TDD збільшується, включаючи тести інтеграції та прийняття.

(Деякі варіанти TDD розглядають "блок" як найменший покроковий крок до бажаної функціональності ...)


вони повинні, але в моєму досвіді насправді вони цього не роблять. Компанії / групи заявляють, що вони роблять TDD, коли все, що вони роблять, - це змусити програмістів пройти тест спочатку з тестами jUnit, а потім використовувати той факт, що все вже було протестовано під час розробки, щоб усунути (або значно зменшити) тестування якості та інтеграції.
jwenting

1
@jwenting не звинувачує методологію в недоліках тих, хто претендує на практику. будь-яким інструментом можна зловживати
Стівен А. Лоу

1
Я цього не роблю, але ви повинні усвідомити, що існує велика різниця між тим, що TDD є в теорії, і тим, що є насправді. Оскільки більшість людей (включаючи ОП), мабуть, лише коли-небудь бачать реальність, різницю слід вказати на них.
jwenting

Враховуючи, що TDD стосується дизайну - навіщо воно включати тестування прийняття? як би це "пригнало" дизайн?
Віталій Ісаєнко

@VitaliiIsaenko приймальні випробування забезпечують найвищий рівень оцінки дизайну
Стівен А. Лоу
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.