Співвідношення між BDD і TDD

Яке співвідношення BDD і TDD?

З того, що я зрозумів, BDD додає до TDD дві основні речі: тести з іменовуванням (забезпечити / слід) та тести прийняття. Чи слід слідкувати за TDD під час розробки BDD? Якщо так, то чи повинні мої тести TDD-модулів бути названі в такому ж стилі, що забезпечує / повинен?

BDD додає цикл навколо циклу TDD.

Отже, ви починаєте з поведінки і нехай це керує вашими тестами, а потім нехай тести сприяють розвитку. В ідеалі BDD керується якимось тестом на прийняття, але це не на 100% необхідне. Поки ви визначаєте очікувану поведінку, ви все в порядку.

Отже, скажімо, що ви пишете сторінку входу.

Почніть зі щасливого шляху:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

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

Існує мова сценаріїв, відома під назвою Gherkin, яка дуже схожа на вищесказане і дозволяє писати тестовий код за положеннями цих поведінок. Вам слід шукати перекладача, заснованого на Gherkin, для вашої звичної структури розробки. Це виходить за межі цієї відповіді.

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

Тому тепер прийшов час перейти на цикл TDD, щоб забезпечити цю функціональність.

Незалежно від того, пишете ви BDD чи ні, ваші тести повинні бути названі загальним синтаксисом. Один з найпоширеніших - описаний вами синтаксис "слід".

Напишіть тест: ShouldAcceptValidDetails. Пройдіть цикл Червоно-Зелений-Рефактор, поки не будете задоволені цим. Ми зараз проходимо тест на поведінку? Якщо ні, напишіть ще один тест: ShouldRedirectToUserDefaultPage. Червоно-зелений-Refactor, поки ви щасливі. Вимийте, промийте, повторіть, поки не виконаєте критерії, викладені в поведінці.

А потім переходимо до наступної поведінки.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Тепер вам не слід було б заздалегідь передбачати це, щоб передати свою попередню поведінку. Ви повинні провалити цей тест у цей момент. Тому поверніться до вашого циклу TDD.

І так далі, поки у вас немає своєї сторінки.

Настійно рекомендую Книгу Rspec дізнатися більше про BDD та TDD, навіть якщо ви не розробник Ruby.

Моє розуміння цього:

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

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

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

Від http://www.metesreau.com/ncraft-workshop/

Gherkin у поєднанні з такими інструментами, як Cucumber та SpecFlow, забезпечують можливість написання специфікацій функцій високого рівня, а потім їх посилання на код, який виконує код програми. Я б заперечував, що саме тут BDD може «відчувати себе» відмінним від TDD, але він все ще робить те саме, лише з деякою додатковою підтримкою інструментів та DSL. Дещо ближче до "традиційного" TDD використовується такі інструменти, як rspec, nspec, spock. Вони трохи більше схожі на той самий процес, який ви робили в «традиційному» TDD, але з більш орієнтованою на поведінку мовою.

У програмі BDD в дії Джона Фергюсона Смарт (настійно рекомендується) він виступає за підхід з подвійним циклом, починаючи з чогось на зразок jBehave на зовнішніх технічних характеристиках зовнішнього рівня, а потім потрапляючи в інструмент, як Спок, для специфікацій низького рівня.

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

Інша частина BDD, яка зараз справді стає чимось, що включає TDD як частину більш широкого процесу, - це вимоги, що пред'являються до бітів. Ідеї, як впорскування функцій, картографування впливів та реальні параметри, є частиною цієї сторони.

Для канонічної відповіді на це, можливо, найкраще знову поїхати до Дана Півночі . Якщо у вашій команді всі розробники, тоді BDD = TDD. Якщо у вашій команді є цілий спектр зацікавлених сторін, BDD наближається до XP, і TDD є його частиною.

Яке співвідношення BDD і TDD?

Вони те саме.

З того, що я зрозумів, BDD додає дві основні речі в TDD: тести іменування (забезпечити / слід)

Це насправді не щось, що BDD "додає". Це просто інша умова, яка покликана полегшити навчання та розуміння TDD.

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

Але це лише слова! Там немає ні фактичної різниці між TDD і BDD.

та приймальні тести.

Тести на прийняття настільки ж важливу частину TDD, як і BDD. Знову ж таки: немає різниці між TDD і BDD: TDD зроблено правильно - BDD, BDD - TDD зроблено правильно.