BDD: co to je, scénáře chování a frameworky

Co je BDD?

Behavior-Driven Development — je evoluce TDD, navržená Danem Northem v roce 2006 jako odpověď na problém formulace testů. V TDD vývojář napíše test, ale otázka „co přesně testovat?“ zůstává otevřená. BDD řeší tento problém přesunem zaměření z testování kódu na popis chování systému z pohledu uživatele.

Klíčovou inovací BDD je společný jazyk pro všechny účastníky projektu. Vývojáři, testeři, analytici a zákazníci diskutují scénáře jednotným jazykem, který je zároveň spustitelným testem. To odstraňuje klasický problém „zkaženého telefonu“, kdy požadavky ztrácejí smysl při předávání od analytika vývojáři.

Historie vzniku BDD

Dan North formuloval BDD v roce 2006 v článku „Introducing BDD“ na blogu ThinkCode. Všiml si, že názvy testů v TDD jsou často formulovány v pojmech implementace („testAddUser“), nikoli v pojmech chování („user should be able to register with email“). BDD nahradil slovo „test“ slovem „should“ a „assert“ slovem „expect“, čímž přesunul zaměření na hodnotu pro uživatele.

BDD jako komunikační praxe

Podle výzkumu Cambridge University (2021) projekty používající BDD scénáře v komunikaci se zákazníkem snižují počet chyb v požadavcích o 35 % ve srovnání s tradičními specifikacemi v textových dokumentech. Spustitelné scénáře nepřipouštějí nejednoznačné formulace — každé Given-When-Then se buď provede, nebo ne.

Jazyk Gherkin a syntaxe

Gherkin — je doménově specifický jazyk používaný frameworky Cucumber a SpecFlow k popisu scénářů chování. Gherkin používá odsazení a klíčová slova pro strukturování scénářů, přičemž zůstává čitelný pro osobu bez technického zázemí.

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

Klíčová slova Gherkinu

Gherkin definuje několik základních klíčových slov. Feature popisuje funkcionalitu, Scenario — konkrétní scénář, Given — předpoklady, When — akci, Then — očekávaný výsledek. Dále se And a But používají ke spojení několika podmínek.

Struktura .feature souboru

Soubory Gherkin mají příponu .feature a ukládají se v adresáři src/test/resources/features/ v Android projektech. Každý soubor začíná popisem Feature, za nímž následuje jeden nebo více Scenario. Pro parametrizaci se používá Scenario Outline s tabulkami Examples — to umožňuje spustit stejný scénář s různými daty.

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     |

Formát Given-When-Then

Given-When-Then — je strukturální vzor pro popis scénářů, převzatý BDD z domain-driven designu. Každý scénář se skládá ze tří částí: předpokladů, akce a očekávaného výsledku. Tento formát přirozeně odpovídá Arrange-Act-Assert z unit testování, ale používá jazyk srozumitelný pro byznys.

Given: kontext

Blok Given popisuje stav systému před zahájením scénáře: jaká data existují, které komponenty jsou aktivní, v jakém režimu aplikace pracuje. V mobilním kontextu to může být „uživatel je přihlášen“, „košík není prázdný“ nebo „zařízení je v offline režimu“.

When: akce

Blok When popisuje událost iniciovanou uživatelem nebo systémem: stisk tlačítka, přijetí push notifikace, odpověď serveru. V mobilních aplikacích to často odpovídá volání metody ViewModel nebo klepnutí na UI prvek.

Then: výsledek

Blok Then popisuje očekávanou změnu stavu: změnu obrazovky, volání API, aktualizaci databáze. Kontroly v Then musí být měřitelné a jednoznačné — stávají se asercemi ve spustitelném kódu.

BDD a TDD: srovnání přístupů

BDD a TDD jsou často zaměňovány, ačkoli jde o různé úrovně disciplíny. TDD — technika návrhu na úrovni kódu: „jak napsat implementaci“. BDD — technika specifikace na úrovni požadavků: „co má systém dělat“.

Vzájemná complementarita v projektu

Nejlepší mobilní projekty používají TDD na úrovni jednotlivých tříd (domain vrstva) a BDD na úrovni scénářů (feature vrstva). To poskytuje dvojité pokrytí: TDD garantuje správnost implementace, BDD — správnost porozumění požadavkům. Google ve své interní praxi používá kombinaci TDD a BDD pro Android aplikace, jak je uvedeno v dokumentaci Android Testing (2024).

Nástroje BDD pro mobilní vývoj

Ekosystém BDD zahrnuje frameworky pro všechny populární platformy a jazyky mobilního vývoje. Výběr nástroje závisí na technologickém stacku a úrovni automatizace.

Cucumber pro Android

Cucumber — nejpopulárnější BDD framework pracující se scénáři Gherkin. Pro Android projekty se používá knihovna io.cucumber:cucumber-android, která se integruje s nástroji pro UI testování Espresso a Compose Test. Cucumber podporuje Kotlin a Java, což z něj činí univerzální volbu pro studia používající oba jazyky.

SpecFlow pro Xamarin

SpecFlow — BDD framework pro .NET ekosystém, používaný v Xamarin.Forms a .NET MAUI projektech. SpecFlow se integruje s NUnit a xUnit a jeho kroky (step definitions) se píší v C#. Pro mobilní projekty SpecFlow umožňuje znovupoužití scénářů mezi Android a iOS verzemi aplikace na společné kódové základně.

Quick/Nimble pro iOS

Pro iOS vývoj ve Swiftu existují BDD frameworky Quick a Nimble. Quick poskytuje DSL pro popis scénářů ve stylu describe/it a Nimble — matchery s čitelnou syntaxí. Ačkoli tyto frameworky nepoužívají Gherkin přímo, implementují princip BDD: popis chování jazykem srozumitelným celému týmu.

Příklady BDD scénářů a kódu

Podívejme se na úplný příklad BDD v Android projektu: scénář objednávky. Nejprve napíšeme Gherkin scénář, poté — step definitions v Kotlinu.

Princip fungování BDD: three amigos

Metodika BDD je založena na setkání three amigos — tří rolí: vývojáře, testera a analytika. Společně píší scénáře před zahájením vývoje, čímž fixují společné porozumění požadavkům. Pokud scénář nevyhovuje žádnému ze tří účastníků — znamená to, že požadavek je formulován nejednoznačně. Tato praxe je popsána v knize „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) a je povinnou součástí BDD procesu ve zralých týmech.

Gherkin scénář objednávky

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 v Kotlinu

Step definitions — kód propojující Gherkin scénář s testovací implementací. Každý krok je metoda s anotací odpovídající klíčovému slovu Gherkinu.

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())
    }
}

Integrace s Cucumber Android

Pro spouštění BDD testů v Android projektu se používá CucumberAndroidJUnitRunner. Ten skenuje .feature soubory v resources, nachází odpovídající step definitions pomocí regulárních výrazů a provádí scénáře jako běžné instrumentační testy. Výsledky jsou formátovány do HTML sestavy srozumitelné zákazníkovi.

// 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

Obtíže zavádění BDD v mobilních projektech

Zavádění BDD do mobilního vývoje je spojeno s řadou praktických obtíží. Vědomí těchto problémů pomáhá týmům vyhnout se zklamání a vybudovat udržitelný BDD proces.

Údržba .feature souborů

Hlavní problém — desynchronizace mezi Gherkin scénáři a produkčním kódem. Pokud vývojáři mění API bez aktualizace step definitions, .feature soubory přestávají odpovídat implementaci. Řešení — spouštění BDD testů v CI/CD pipeline a vyžadování zeleného statusu pro merge request. Praxe „BDD as a gating mechanism“ je popsána v dokumentaci Cucumber (2024) a je standardem v průmyslu.

Výkon BDD testů

BDD scénáře na Cucumberu se provádějí prostřednictvím instrumentačních testů na Android zařízení nebo emulátoru. To je 10–50krát pomalejší než běžné unit testy na JVM. Jedno akceptační testování může trvat 20–30 minut u velké Android aplikace. Doporučuje se vyčlenit BDD testy do samostatného CI úkolu a spouštět je v noci, zatímco unit testy — při každém pushi. Taková strategie vyvažuje rychlost zpětné vazby a pokrytí scénářů.

Školení týmu v Gherkinu

Přechod na BDD vyžaduje školení nejen vývojářů, ale také analytiků a testerů. Gherkin je jednoduchý jazyk, ale psaní dobrých scénářů vyžaduje praxi. Typické chyby začátečníků: příliš dlouhé scénáře (více než 10 kroků), míchání Given-When-Then, používání technických termínů v business scénářích. Podle BDD Academy (2024) týmy potřebují v průměru 4–6 sprintů k dosažení zralosti v psaní BDD scénářů.