BDD: wat is het, gedragsscenario's en frameworks

Wat is BDD?

Behavior-Driven Development — is een evolutie van TDD, voorgesteld door Dan North in 2006 als antwoord op het probleem van het formuleren van tests. In TDD schrijft de ontwikkelaar een test, maar de vraag „wat precies testen?“ blijft open. BDD lost dit probleem op door de focus te verleggen van het testen van code naar het beschrijven van het gedrag van het systeem vanuit het perspectief van de gebruiker.

De belangrijkste innovatie van BDD — gemeenschappelijke taal voor alle projectdeelnemers. Ontwikkelaars, testers, analisten en klanten bespreken scenario's in een uniforme taal die tegelijkertijd een uitvoerbare test is. Dit elimineert het klassieke probleem van „kapotte telefoon“, waarbij vereisten hun betekenis verliezen bij overdracht van analist naar ontwikkelaar.

Geschiedenis van BDD

Dan North formuleerde BDD in 2006 in het artikel ‚Introducing BDD' op de blog ThinkCode. Hij merkte op dat testnamen in TDD vaak worden geformuleerd in termen van implementatie („testAddUser“), niet in termen van gedrag („user should be able to register with email“). BDD verving het woord „test“ door „should“ en „assert“ door „expect“, waardoor de focus verschoof naar waarde voor de gebruiker.

BDD als communicatiepraktijk

Volgens onderzoek van Cambridge University (2021) verminderen projecten die BDD-scenario's gebruiken in communicatie met de klant het aantal fouten in vereisten met 35% in vergelijking met traditionele specificaties in tekstdocumenten. Uitvoerbare scenario's laten geen dubbelzinnige formuleringen toe — elke Given-When-Then wordt uitgevoerd of niet.

Gherkin-taal en syntax

Gherkin — is een domeinspecifieke taal, gebruikt door de frameworks Cucumber en SpecFlow voor het beschrijven van gedragsscenario's. Gherkin gebruikt inspringing en trefwoorden voor het structureren van scenario's, terwijl het leesbaar blijft voor iemand zonder technische achtergrond.

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

Trefwoorden van Gherkin

Gherkin definieert verschillende basis-trefwoorden. Feature beschrijft de functionaliteit, Scenario — het concrete scenario, Given — de voorwaarden, When — de actie, Then — het verwachte resultaat. Daarnaast worden And en But gebruikt om meerdere voorwaarden te combineren.

Structuur van .feature-bestand

Gherkin-bestanden hebben de extensie .feature en worden opgeslagen in de map src/test/resources/features/ in Android-projecten. Elk bestand begint met een Feature-beschrijving, gevolgd door een of meer Scenario's. Voor parametrisatie wordt Scenario Outline gebruikt met Examples-tabellen — dit maakt het mogelijk hetzelfde scenario met verschillende gegevens uit te voeren.

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

Given-When-Then — is een structureel patroon voor het beschrijven van scenario's, overgenomen door BDD uit domain-driven design. Elk scenario bestaat uit drie delen: voorwaarden, actie en verwacht resultaat. Dit formaat komt natuurlijk overeen met Arrange-Act-Assert uit unittesten, maar gebruikt voor de business begrijpelijke taal.

Given: context

Het Given-blok beschrijft de toestand van het systeem voor aanvang van het scenario: welke gegevens bestaan, welke componenten actief zijn, in welke modus de applicatie werkt. In mobiele context kan dit zijn „gebruiker is ingelogd“, „winkelwagen is niet leeg“ of „apparaat is offline“.

When: actie

Het When-blok beschrijft de gebeurtenis geïnitieerd door de gebruiker of het systeem: indrukken van een knop, ontvangen van een pushmelding, antwoord van de server. In mobiele applicaties komt dit vaak overeen met het aanroepen van een ViewModel-methode of het tikken op een UI-element.

Then: resultaat

Het Then-blok beschrijft de verwachte toestandsverandering: schermwijziging, API-aanroep, database-update. Controles in Then moeten meetbaar en ondubbelzinnig zijn — ze worden assertions in uitvoerbare code.

BDD en TDD: vergelijking van benaderingen

BDD en TDD worden vaak verward, hoewel het verschillende niveaus van discipline zijn. TDD — is een ontwerptechniek op codeniveau: „hoe implementatie te schrijven“. BDD — is een specificatietechniek op vereistenniveau: „wat het systeem moet doen“.

Wederzijdse aanvulling in project

De beste mobiele projecten gebruiken TDD op het niveau van individuele klassen (domain-laag) en BDD op het niveau van scenario's (feature-laag). Dit geeft dubbele dekking: TDD garandeert correctheid van implementatie, BDD — correctheid van begrip van vereisten. Google gebruikt in zijn interne praktijk een combinatie van TDD en BDD voor Android-applicaties, zoals aangegeven in de documentatie Android Testing (2024).

BDD-tools voor mobiele ontwikkeling

Het BDD-ecosysteem omvat frameworks voor alle populaire platforms en talen van mobiele ontwikkeling. De keuze van het instrument hangt af van de technologiestack en het automatiseringsniveau.

Cucumber voor Android

Cucumber — het populairste BDD-framework dat werkt met Gherkin-scenario's. Voor Android-projecten wordt de bibliotheek io.cucumber:cucumber-android gebruikt, die integreert met UI-testtools Espresso en Compose Test. Cucumber ondersteunt Kotlin en Java, wat het een universele keuze maakt voor studio's die beide talen gebruiken.

SpecFlow voor Xamarin

SpecFlow — BDD-framework voor het .NET-ecosysteem, gebruikt in Xamarin.Forms en .NET MAUI-projecten. SpecFlow integreert met NUnit en xUnit, en zijn stappen (step definitions) worden geschreven in C#. Voor mobiele projecten maakt SpecFlow het mogelijk scenario's te hergebruiken tussen Android- en iOS-versies van de applicatie op een gemeenschappelijke codebase.

Quick/Nimble voor iOS

Voor iOS-ontwikkeling in Swift bestaan de BDD-frameworks Quick en Nimble. Quick biedt een DSL voor het beschrijven van scenario's in describe/it-stijl, en Nimble — matchers met leesbare syntax. Hoewel deze frameworks Gherkin niet direct gebruiken, implementeren ze het BDD-principe: beschrijving van gedrag in een voor het hele team begrijpelijke taal.

Voorbeelden van BDD-scenario's en code

Laten we een volledig voorbeeld van BDD in een Android-project bekijken: het bestel-scenario. Eerst schrijven we het Gherkin-scenario, daarna — step definitions in Kotlin.

Werkingsprincipe van BDD: three amigos

De BDD-methodologie is gebaseerd op de bijeenkomst van three amigos — drie rollen: ontwikkelaar, tester en analist. Ze schrijven samen scenario's voordat de ontwikkeling begint, waarbij ze een gemeenschappelijk begrip van de vereisten vastleggen. Als het scenario voor geen van de drie deelnemers geschikt is — betekent dit dat de vereiste dubbelzinnig is geformuleerd. Deze praktijk wordt beschreven in het boek „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) en is een verplicht onderdeel van het BDD-proces in volwassen teams.

Gherkin-bestel-scenario

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 in Kotlin

Step definitions — code die het Gherkin-scenario verbindt met de testimplementatie. Elke stap is een methode met een annotatie die overeenkomt met het Gherkin-trefwoord.

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

Integratie met Cucumber Android

Voor het uitvoeren van BDD-tests in een Android-project wordt CucumberAndroidJUnitRunner gebruikt. Het scant .feature-bestanden in de resources, vindt overeenkomstige step definitions via reguliere expressies en voert de scenario's uit als gewone instrumentele tests. Resultaten worden geformatteerd in een HTML-rapport dat begrijpelijk is voor de klant.

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

Uitdagingen bij het implementeren van BDD in mobiele projecten

Het implementeren van BDD in mobiele ontwikkeling gaat gepaard met een aantal praktische moeilijkheden. Bewustzijn van deze problemen helpt teams teleurstelling te voorkomen en een duurzaam BDD-proces op te bouwen.

Onderhoud van .feature-bestanden

Het grootste probleem — desynchronisatie tussen Gherkin-scenario's en productiecode. Als ontwikkelaars de API wijzigen zonder de step definitions bij te werken, komen .feature-bestanden niet meer overeen met de implementatie. Oplossing — BDD-tests uitvoeren in de CI/CD-pipeline en een groene status vereisen voor merge request. De praktijk ‚BDD as a gating mechanism' wordt beschreven in de documentatie van Cucumber (2024) en is een standaard in de industrie.

Prestaties van BDD-tests

BDD-scenario's in Cucumber worden uitgevoerd via instrumentele tests op een Android-apparaat of emulator. Dit is 10–50 keer langzamer dan gewone unittests op de JVM. Een enkele acceptatietest kan 20–30 minuten duren voor een grote Android-applicatie. Het wordt aanbevolen BDD-tests in een aparte CI-job te plaatsen en 's nachts uit te voeren, en unittests bij elke push. Een dergelijke strategie balanceert de snelheid van feedback en de dekkingsgraad van scenario's.

Teamtraining in Gherkin

De overgang naar BDD vereist training van niet alleen ontwikkelaars, maar ook analisten en testers. Gherkin is een eenvoudige taal, maar het schrijven van goede scenario's vereist oefening. Typische beginnersfouten: te lange scenario's (meer dan 10 stappen), het door elkaar halen van Given-When-Then, het gebruik van technische termen in business-scenario's. Volgens BDD Academy (2024) hebben teams gemiddeld 4–6 sprints nodig om volwassenheid te bereiken in het schrijven van BDD-scenario's.