Як використовувати одиничні тести при використанні BDD?

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

Є один практичний момент, який я не розумію, подумав: є файл .feature, в якому БА запише всю очікувану поведінку, в якій би мала система. Як бакалавр, він не має уявлення про те, як будується система, тому ми напишемо щось подібне:

+ Сценарій 1: Обліковий запис у кредит +

З огляду на рахунок в кредит

І карта дійсна

А дозатор містить готівку

Коли замовник вимагає готівку

Потім переконайтесь, що рахунок рахунку списаний та переконайтеся, що кошти будуть видані

І гарантуйте повернення картки

Добре, це чудово, але є багато частин системи, які співпрацюватимуть так, щоб це могло статися (подумайте про акаунт obj, Dispenser obj, Customer obj тощо). Для мене це виглядає як інтеграційний тест.

Мені хотілося б провести одиничні тести. Як перевірити код, який перевіряє, чи є у дозатора гроші? Або що готівка видається? Або що рахунок списується при необхідності? Як я можу змішувати одиничні тести з тестами "Створено BA"?

Розробка поведінки та тестова розробка є безкоштовним, але не є заміною один одному.

Як поводиться додаток, описано в тестах прийняття, які, згідно BDD, були б особливостями та сценаріями, написаними огірком.

Докладні деталі того, як працює кожен невеликий компонент, описані в Тестових блоках. Результати одиничних тестів підтримують сценарії, написані вами «Огірок».

Уявіть собі процес побудови автомобіля.

По-перше, команда продукту придумує свої ідеї, а згодом зводить їх до сценаріїв використання:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

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

Наведений вище сценарій - це тест "Велика картина". Кожен компонент транспортного засобу потребує тестів "Малий малюнок", щоб переконатися, що вони функціонують належним чином у цілому.

Створення та тестування програмного забезпечення багато в чому однакове. Ви проектуєте зверху вниз, потім будуєте знизу вгору. Навіщо мати двері, які піднімаються, якщо ви навіть не можете запустити двигун? Навіщо мати стартер, якщо у вас немає акумулятора?

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

Після того, як пройдуть одиничні тести, починайте впроваджувати сценарії огірка. Після того, як вони пройдуть, ви доставили те, про що попросила команда продуктів.

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

Власне, ні, BDD не є "наступним кроком" від TDD. Це є TDD. Або точніше, це перефразовування TDD.

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

Отже, вони перефразовували TDD з точки зору специфіки поведінки. "Тести" та "тестові випадки" тепер є "прикладами", "одиницями" є "поведінка", "твердження" - "очікуваннями" тощо.

Однак методологія все одно та сама. Ви починаєте з тесту на прийняття (я маю на увазі "особливість"), збільшення масштабу до одиничного тесту (я маю на увазі "приклад"), зменшення масштабу тощо

Мені хотілося б провести одиничні тести. Як перевірити код, який перевіряє, чи є у дозатора гроші? Або що готівка видається? Або що рахунок списується при необхідності? Як я можу змішувати одиничні тести з тестами "Створено BA"?

Так само, як і в TDD. Ви можете писати свої функції та приклади в різні рамки (наприклад, огірок та RSpec) або навіть на різних мовах (наприклад, написання прикладів для проекту C на C та функцій у FIT / Fitnesse), ви можете використовувати єдину рамку функцій для обох ( наприклад, написання прикладів та особливостей у огірку) або ви можете використовувати рамки для одного прикладу для обох (наприклад, написання обох у RSpec). Вам навіть не потрібно використовувати рамку взагалі.

Прикладом TDD-done-right (який є ідентичним BDD), що використовує лише єдиний фреймворк, є сам JUnit, який містить суміш одиничних тестів (прикладів) та функціональних / інтеграційних тестів (особливостей), всі написані в самому JUnit.

Я вважаю, що Кент Бек називає це "збільшенням". Почніть з високого рівня, потім "збільшуйте" деталі, а потім знову відступайте.

Відмова: Я не є експертом у галузі BDD, але намагаюся висловити свою точку зору на статтю, з якою ви пов’язані.

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

Тому щоразу, коли ви пишете тест для нового методу, ви повинні вибрати ім'я методу - і саме тоді входить BDD. Вибираючи назви методів, використовуючи бізнес-терміни за вищевказаним сценарієм, і вибираючи їх у спосіб, що описує поведінка вашого класу, ви займаєтесь BDD. Щоразу, коли ви запитуєте себе "чи потрібно мені додавати подальші тести", ви можете переглянути сценарії, надані вашим бакалавром, і перевірити, чи повністю ви виконали всі необхідні частини. Якщо ні, вам потрібно буде додати більше тестів.

Автор статті також пропонує використовувати більш іменну схему іменування при виборі імен ваших тестів, тому він пропонує замінити JUnit інструментом, який не покладається на схему іменування, з якої кожен тестовий випадок повинен починатися з назва "тест". Хоча я не знаю JBehave, я думаю, що це головна відмінність цього інструменту від Junit.

Більше того, сценарії BDD також будуть кресленням для інтеграційних тестів - які ви, як правило, додаватимете після того, як TDD розробив назви методів і після того, як ви додасте розумну кількість одиниць тестів.

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