BDD: какво е, сценарии на поведение и рамки

Какво е BDD?

Behavior-Driven Development — еволюция на TDD, предложена от Dan North през 2006 г. като отговор на проблема с формулирането на тестове. В TDD разработчикът пише тест, но въпросът „какво точно да тестваме?“ остава отворен. BDD решава този проблем, премествайки фокуса от тестване на код към описание на поведението на системата от гледна точка на потребителя.

Ключовото нововъведение на BDD — общ език за всички участници в проекта. Разработчици, тестери, анализатори и клиенти обсъждат сценарии на единен език, който едновременно е изпълним тест. Това елиминира класическия проблем на „разваления телефон“, когато изискванията губят смисъл при предаване от анализатор на разработчик.

История на възникване на BDD

Dan North формулира BDD през 2006 г. в статията „Introducing BDD“ в блога ThinkCode. Той забелязва, че имената на тестовете в TDD често се формулират в термини на имплементация („testAddUser“), а не в термини на поведение („user should be able to register with email“). BDD заменя думата „test“ с „should“ и „assert“ с „expect“, премествайки фокуса върху стойността за потребителя.

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

Според изследване на Cambridge University (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 трябва да бъдат измерими и еднозначни — те стават асерции в изпълнимия код.

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 — matcher-и с четим синтаксис. Въпреки че тези рамки не използват 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 сценариите и продукционния код. Ако разработчиците променят API, без да актуализират step definitions, .feature файловете престават да съответстват на имплементацията. Решение — стартиране на BDD тестове в CI/CD pipeline и изискване на зелен статус за 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 сценарии.