BDD: що це, сценарії поведінки та фреймворки

Що таке BDD?

Behavior-Driven Development — це еволюція TDD, запропонована Dan North у 2006 році як відповідь на проблему формулювання тестів. У TDD розробник пише тест, але питання «що саме тестувати?» залишається відкритим. BDD вирішує цю проблему, переводячи фокус з тестування коду на опис поведінки системи з точки зору користувача.

Ключове нововведення BDD — спільна мова для всіх учасників проєкту. Розробники, тестувальники, аналітики та замовники обговорюють сценарії єдиною мовою, яка одночасно є виконуваним тестом. Це усуває класичну проблему «зіпсованого телефону», коли вимоги втрачають сенс при передачі від аналітика до розробника.

Історія виникнення BDD

Dan North сформулював BDD у 2006 році в статті «Introducing BDD» у блозі ThinkCode. Він помітив, що назви тестів у TDD часто формулюються в термінах реалізації («testAddUser»), а не в термінах поведінки («користувач повинен мати можливість зареєструватися за email»). BDD замінив слово «test» на «should» та «assert» на «expect», змістивши фокус на цінність для користувача.

BDD як комунікаційна практика

За даними дослідження Кембриджського університету (2021), проєкти, які використовують BDD-сценарії в комунікації з замовником, скорочують кількість помилок у вимогах на 35% порівняно з традиційними специфікаціями в текстових документах. Виконувані сценарії не допускають двозначних формулювань — кожен Given-When-Then або виконується, або ні.

Мова Gherkin та синтаксис

Gherkin — це предметно-орієнтована мова, яка використовується фреймворками Cucumber та SpecFlow для опису сценаріїв поведінки. Gherkin використовує відступи та ключові слова для структурування сценаріїв, залишаючись при цьому читабельним для людини без технічного бекграунду.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Ключові слова Gherkin

Gherkin визначає кілька базових ключових слів. Feature описує функціональність, Scenario — конкретний сценарій, Given — передумови, When — дію, Then — очікуваний результат. Додатково And та But використовуються для об'єднання кількох умов.

Структура .feature файлу

Файли Gherkin мають розширення .feature та зберігаються в директорії src/test/resources/features/ в Android-проєктах. Кожен файл починається з опису Feature, за яким слідує один або кілька Scenario. Для параметризації використовується Scenario Outline з таблицями Examples — це дозволяє запускати один і той самий сценарій з різними даними.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Формат Given-When-Then

Given-When-Then — це структурний шаблон опису сценаріїв, запозичений BDD з domain-driven design. Кожен сценарій складається з трьох частин: передумови, дії та очікуваного результату. Цей формат природним чином відповідає Arrange-Act-Assert з unit-тестування, але використовує зрозумілу бізнесу мову.

Given: контекст

Блок Given описує стан системи перед початком сценарію: які дані існують, які компоненти активні, в якому режимі працює додаток. У мобільному контексті це може бути «користувач авторизований», «кошик не порожній» або «пристрій знаходиться в офлайн-режимі».

When: дія

Блок When описує подію, ініційовану користувачем або системою: натискання кнопки, отримання push-сповіщення, відповідь сервера. У мобільних додатках це часто відповідає виклику методу ViewModel або натисканню на UI-елемент.

Then: результат

Блок Then описує очікувану зміну стану: зміна екрану, виклик API, оновлення бази даних. Перевірки в Then мають бути вимірюваними та однозначними — вони стають assertions у виконуваному коді.

BDD та TDD: порівняння підходів

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

Взаємодоповнення в проєкті

Найкращі мобільні проєкти використовують TDD на рівні окремих класів (domain-шар) та BDD на рівні сценаріїв (feature-шар). Це дає подвійне покриття: TDD гарантує коректність реалізації, BDD — коректність розуміння вимог. Google у своїй внутрішній практиці використовує комбінацію TDD та BDD для Android-додатків, як зазначено в документації Android Testing (2024).

Інструменти BDD для мобільної розробки

Екосистема BDD включає фреймворки для всіх популярних платформ та мов мобільної розробки. Вибір інструменту залежить від стеку технологій та рівня автоматизації.

Cucumber для Android

Cucumber — найпопулярніший BDD-фреймворк, який працює з Gherkin-сценаріями. Для Android-проєктів використовується бібліотека io.cucumber:cucumber-android, яка інтегрується з інструментами UI-тестування Espresso та Compose Test. Cucumber підтримує Kotlin та Java, що робить його універсальним вибором для студій, які використовують обидві мови.

SpecFlow для Xamarin

SpecFlow — BDD-фреймворк для .NET-екосистеми, який використовується в Xamarin.Forms та .NET MAUI проєктах. SpecFlow інтегрується з NUnit та xUnit, а його кроки (step definitions) пишуться на C#. Для мобільних проєктів SpecFlow дозволяє перевикористовувати сценарії між Android та iOS версіями додатка на спільній кодовій базі.

Quick/Nimble для iOS

Для iOS-розробки на Swift існують BDD-фреймворки Quick та Nimble. Quick надає DSL для опису сценаріїв у стилі describe/it, а Nimble — matchers з читабельним синтаксисом. Хоча ці фреймворки не використовують Gherkin безпосередньо, вони реалізують принцип BDD: опис поведінки мовою, зрозумілою всій команді.

Приклади BDD-сценаріїв та коду

Розглянемо повний приклад BDD в Android-проєкті: сценарій оформлення замовлення. Спочатку пишемо Gherkin-сценарій, потім — step definitions на Kotlin.

Принцип роботи BDD: three amigos

Методологія BDD заснована на зустрічі three amigos — трьох ролей: розробник, тестувальник та аналітик. Вони спільно пишуть сценарії до початку розробки, фіксуючи спільне розуміння вимог. Якщо сценарій не проходить жоден із трьох учасників — значить, вимога сформульована неоднозначно. Ця практика описана в книзі «Discovery: Explore Behaviour Using Examples» (Gáspár & North, 2021) і є обов'язковою частиною BDD-процесу в зрілих командах.

Gherkin-сценарій оформлення замовлення

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions на Kotlin

Step definitions — це код, який пов'язує сценарій Gherkin з тестовою реалізацією. Кожен крок — це метод з анотацією, що відповідає ключовому слову Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Інтеграція з Cucumber Android

Для запуску BDD-тестів в Android-проєкті використовується CucumberAndroidJUnitRunner. Він сканує .feature файли в ресурсах, знаходить відповідні step definitions за регулярними виразами та виконує сценарії як звичайні інструментальні тести. Результати форматуються в HTML-звіт, зрозумілий замовнику.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Складнощі впровадження BDD в мобільних проєктах

Впровадження BDD в мобільну розробку пов'язане з рядом практичних труднощів. Усвідомлення цих проблем допомагає командам уникнути розчарування та побудувати стійкий BDD-процес.

Підтримка .feature файлів

Основна проблема — розсинхронізація між Gherkin-сценаріями та production-кодом. Якщо розробники змінюють API, не оновлюючи step definitions, .feature файли перестають відповідати реалізації. Рішення — запускати BDD-тести в CI/CD пайплайні та вимагати зеленого статусу для merge request. Практика «BDD as a gating mechanism» описана в документації Cucumber (2024) і є стандартом в індустрії.

Продуктивність BDD-тестів

BDD-сценарії на Cucumber виконуються через інструментальні тести на Android-пристрої або емуляторі. Це в 10–50 разів повільніше за звичайні unit-тести на JVM. Одне приймальне тестування може займати 20–30 хвилин для великого Android-додатка. Рекомендується виділяти BDD-тести в окремий CI-джоб та запускати їх вночі, а unit-тести — на кожен push. Така стратегія балансує швидкість зворотного зв'язку та покриття сценаріїв.

Навчання команди Gherkin

Перехід на BDD вимагає навчання не лише розробників, але й аналітиків з тестувальниками. Gherkin — проста мова, але написання хороших сценаріїв вимагає практики. Типові помилки новачків: занадто довгі сценарії (більше 10 кроків), змішування Given-When-Then, використання технічних термінів у бізнес-сценаріях. За даними BDD Academy (2024), командам потрібно в середньому 4–6 спринтів, щоб досягти зрілості в написанні BDD-сценаріїв.