Що таке Лондонська та Чиказька школи TDD?

Я чув про стиль Лондона проти Чикаго (іноді його називають стилем Детройту) розвитку Test Driven Development (TDD).

Семінар групи користувача Юта Екстремальне програмування:

TDD у стилі взаємодії також називають мокістським або лондонським стилем після лондонського клубу Extreme Tuesday, де він став популярним. Зазвичай він контрастує з стилем Детройту або класичним TDD, який базується на державі.

Майстерня Джейсона Гормана :

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

Повідомлення Classic TDD або "London School"? Джейсон Горман був корисним, але його приклади мене збентежили, оскільки він використовує два різні приклади замість одного прикладу з обома підходами. Які відмінності? Коли ви використовуєте кожен стиль?

Припустимо, у вас є клас під назвою "головна книга" метод під назвою "обчислити", який використовує "Калькулятор", щоб робити різні типи обчислень залежно від аргументів, переданих "обчислити", наприклад "помножити (x, y)" або "відняти ( х, у) ".

Тепер, припустимо, ви хочете перевірити, що відбувається, коли ви телефонуєте ledger.calculate ("5 * 7").

У Лондонській школі / школі взаємодії ви б хотіли стверджувати, чи викликали Calculator.multiply (5,7). Для цього корисні різні глузуючі рамки, і це може бути дуже корисно, якщо, наприклад, у вас немає власності на об’єкт "Калькулятор" (припустимо, це зовнішній компонент або послуга, яку ви не можете перевірити безпосередньо, але ви робите знайте, вам потрібно зателефонувати певним чином).

Чиказька / державна школа дозволить вам стверджувати, чи є результат 35. Рамки jUnit / nUnit, як правило, спрямовані на це.

Обидва є дійсними та важливими тестами.

Стаття « Знущання не є заглушками» Мартіна Фаулера - це хороший вступ до теми.

Залежно від обраного вами стилю дизайну (та принципів дизайну, на основі яких ви будуєте свої програми), існує щонайменше два способи побачити об’єкт:

1. Як одиниця, яка виконує обчислення на основі входів. В результаті цього обчислення об'єкт може повернути значення або змінити його стан.
2. Як активний елемент, який спілкується з іншими елементами в системі шляхом передачі повідомлення.

У першому випадку вас цікавить, що виходить з обробки або в якому стані об’єкт залишається після цієї обробки. Ось де такі способи, як assertEquals()введення малюнка. У цьому випадку не має великого значення, які інші об’єкти були задіяні в обробці, які методи були названі і т. Д. Цей вид перевірки називається державною верифікацією і є "класичним" стилем.

У другому випадку, оскільки більшість об'єктів навіть не повертають жодного результату (наприклад, voidметоди на Java), вас більше цікавить, як об’єкти спілкуються один з одним і чи передають вони правильні повідомлення за обставин, накладених тестом. Ці взаємодії зазвичай перевіряються за допомогою макетних рамок. Цей вид верифікації називається верифікацією на основі поведінки або взаємодії. Одним із її наслідків є техніка, яка називається Behavior Driven Development, за допомогою якої ви розробляєте клас, припускаючи, що його співпрацівники вже існують (навіть якщо вони ще не існували), тож ви можете кодувати їх інтерфейси.

Зауважте, що це не вибір або / або вибір. Ви можете мати стиль дизайну, який поєднує обидва підходи, щоб отримати найкраще з кожного.