BDD: Was es ist, Verhaltensszenarien und Frameworks

Was ist BDD?

Behavior-Driven Development ist eine Weiterentwicklung von TDD, die Dan North 2006 als Antwort auf das Problem der Testformulierung vorschlug. Bei TDD schreibt der Entwickler einen Test, aber die Frage „was genau testen?“ bleibt offen. BDD löst dieses Problem, indem es den Fokus vom Testen von Code auf die Beschreibung des Systemverhaltens aus Benutzersicht verlagert.

Die wichtigste Neuerung von BDD ist eine gemeinsame Sprache für alle Projektbeteiligten. Entwickler, Tester, Analysten und Kunden diskutieren Szenarien in einer einheitlichen Sprache, die gleichzeitig als ausführbarer Test dient. Dies beseitigt das klassische „Stille Post“-Problem, bei dem Anforderungen auf dem Weg vom Analysten zum Entwickler ihren Sinn verlieren.

Die Entstehungsgeschichte von BDD

Dan North formulierte BDD 2006 in seinem Artikel „Introducing BDD“ auf dem Blog ThinkCode. Er stellte fest, dass Testnamen in TDD oft in Implementierungsbegriffen („testAddUser“) statt in Verhaltensbegriffen („Benutzer sollte sich mit E-Mail registrieren können“) formuliert werden. BDD ersetzte das Wort „test“ durch „should“ und „assert“ durch „expect“ und verlagerte den Fokus auf den Benutzerwert.

BDD als Kommunikationspraxis

Laut einer Studie der University of Cambridge (2021) reduzieren Projekte, die BDD-Szenarien in der Kommunikation mit dem Kunden einsetzen, Anforderungsfehler um 35% im Vergleich zu herkömmlichen textspezifischen Dokumenten. Ausführbare Szenarien lassen keine mehrdeutigen Formulierungen zu — jedes Given-When-Then besteht entweder oder fällt durch.

Gherkin-Sprache und Syntax

Gherkin ist eine domänenspezifische Sprache, die von den Frameworks Cucumber und SpecFlow zur Beschreibung von Verhaltensszenarien verwendet wird. Gherkin verwendet Einrückungen und Schlüsselwörter, um Szenarien zu strukturieren, und bleibt dabei für Menschen ohne technischen Hintergrund lesbar.

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-Schlüsselwörter

Gherkin definiert mehrere grundlegende Schlüsselwörter. Feature beschreibt die Funktionalität, Scenario beschreibt ein konkretes Szenario, Given beschreibt die Vorbedingungen, When beschreibt die Aktion, Then beschreibt das erwartete Ergebnis. Zusätzlich werden And und But verwendet, um mehrere Bedingungen zu kombinieren.

.feature-Dateistruktur

Gherkin-Dateien haben die Erweiterung .feature und werden im Verzeichnis src/test/resources/features/ in Android-Projekten gespeichert. Jede Datei beginnt mit einer Feature-Beschreibung, gefolgt von einem oder mehreren Scenarios. Zur Parametrisierung wird Scenario Outline mit Examples-Tabellen verwendet — dies ermöglicht die Ausführung desselben Szenarios mit unterschiedlichen Daten.

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

Given-When-Then ist ein strukturelles Muster zur Beschreibung von Szenarien, das von BDD aus dem Domain-Driven Design übernommen wurde. Jedes Szenario besteht aus drei Teilen: Vorbedingungen, Aktion und erwartetem Ergebnis. Dieses Format entspricht natürlicherweise Arrange-Act-Assert aus dem Unit-Testing, verwendet jedoch eine geschäftsfreundliche Sprache.

Given: Kontext

Der Given-Block beschreibt den Systemzustand vor Beginn des Szenarios: welche Daten vorhanden sind, welche Komponenten aktiv sind, in welchem Modus die Anwendung läuft. Im mobilen Kontext kann dies „Der Benutzer ist angemeldet“, „Der Warenkorb ist nicht leer“ oder „Das Gerät ist im Offline-Modus“ sein.

When: Aktion

Der When-Block beschreibt ein vom Benutzer oder System ausgelöstes Ereignis: Drücken einer Taste, Empfangen einer Push-Benachrichtigung, Serverantwort. In mobilen Anwendungen entspricht dies oft dem Aufruf einer ViewModel-Methode oder dem Klicken auf ein UI-Element.

Then: Ergebnis

Der Then-Block beschreibt die erwartete Zustandsänderung: Bildschirmwechsel, API-Aufruf, Datenbankupdate. Prüfungen in Then müssen messbar und eindeutig sein — sie werden zu Assertions im ausführbaren Code.

BDD und TDD: Vergleich der Ansätze

BDD und TDD werden oft verwechselt, obwohl sie unterschiedliche Disziplin-Ebenen sind. TDD ist eine Entwurfstechnik auf Code-Ebene: „Wie schreibe ich die Implementierung“. BDD ist eine Spezifikationstechnik auf Anforderungsebene: „Was soll das System tun“.

Komplementarität im Projekt

Die besten mobilen Projekte verwenden TDD auf der Ebene einzelner Klassen (Domänenschicht) und BDD auf der Szenario-Ebene (Featureschicht). Dies bietet eine doppelte Abdeckung: TDD garantiert die Korrektheit der Implementierung, BDD garantiert die Korrektheit des Anforderungsverständnisses. Google verwendet in seiner internen Praxis eine Kombination aus TDD und BDD für Android-Anwendungen, wie in der Android-Testing-Dokumentation (2024) angegeben.

BDD-Tools für die mobile Entwicklung

Das BDD-Ökosystem umfasst Frameworks für alle gängigen mobilen Entwicklungsplattformen und Sprachen. Die Wahl des Tools hängt vom Technologie-Stack und Automatisierungsgrad ab.

Cucumber für Android

Cucumber ist das beliebteste BDD-Framework und arbeitet mit Gherkin-Szenarien. Für Android-Projekte wird die Bibliothek io.cucumber:cucumber-android verwendet, die sich mit den UI-Testtools Espresso und Compose Test integriert. Cucumber unterstützt Kotlin und Java, was es zu einer universellen Wahl für Studios macht, die beide Sprachen verwenden.

SpecFlow für Xamarin

SpecFlow ist ein BDD-Framework für das .NET-Ökosystem, das in Xamarin.Forms- und .NET MAUI-Projekten verwendet wird. SpecFlow integriert sich mit NUnit und xUnit, und seine Step Definitions werden in C# geschrieben. Für mobile Projekte ermöglicht SpecFlow die Wiederverwendung von Szenarien zwischen Android- und iOS-Versionen der Anwendung auf einer gemeinsamen Codebasis.

Quick/Nimble für iOS

Für die iOS-Entwicklung in Swift gibt es die BDD-Frameworks Quick und Nimble. Quick bietet ein DSL zur Beschreibung von Szenarien im describe/it-Stil, und Nimble bietet Matcher mit lesbarer Syntax. Obwohl diese Frameworks Gherkin nicht direkt verwenden, implementieren sie das BDD-Prinzip: Beschreibung des Verhaltens in einer für das gesamte Team verständlichen Sprache.

BDD-Szenarien und Code-Beispiele

Betrachten wir ein vollständiges BDD-Beispiel in einem Android-Projekt: ein Bestellabschluss-Szenario. Zuerst schreiben wir ein Gherkin-Szenario, dann Step Definitions in Kotlin.

BDD-Arbeitsprinzip: Three Amigos

Die BDD-Methodik basiert auf dem Three Amigos-Meeting — drei Rollen: Entwickler, Tester und Analyst. Sie schreiben gemeinsam Szenarien vor Entwicklungsbeginn und etablieren ein gemeinsames Verständnis der Anforderungen. Wenn einer der drei Teilnehmer das Szenario nicht versteht, bedeutet dies, dass die Anforderung mehrdeutig formuliert ist. Diese Praxis wird im Buch „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) beschrieben und ist ein obligatorischer Teil des BDD-Prozesses in reifen Teams.

Gherkin-Szenario: Bestellabschluss

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 sind Code, der Gherkin-Szenarien mit der Testimplementierung verbindet. Jeder Schritt ist eine Methode mit einer Annotation, die einem Gherkin-Schlüsselwort entspricht.

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

Integration mit Cucumber Android

Zum Ausführen von BDD-Tests in einem Android-Projekt wird CucumberAndroidJUnitRunner verwendet. Es scannt .feature-Dateien in Ressourcen, findet entsprechende Step Definitions durch reguläre Ausdrücke und führt Szenarien als normale instrumentierte Tests aus. Die Ergebnisse werden in einem für den Kunden verständlichen HTML-Bericht formatiert.

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

Herausforderungen bei der Einführung von BDD in mobilen Projekten

Die Einführung von BDD in der mobilen Entwicklung bringt eine Reihe praktischer Schwierigkeiten mit sich. Das Verständnis dieser Probleme hilft Teams, Frustration zu vermeiden und einen nachhaltigen BDD-Prozess aufzubauen.

Wartung von .feature-Dateien

Das Hauptproblem ist die Desynchronisation zwischen Gherkin-Szenarien und Produktionscode. Wenn Entwickler APIs ändern, ohne die Step Definitions zu aktualisieren, stimmen die .feature-Dateien nicht mehr mit der Implementierung überein. Die Lösung besteht darin, BDD-Tests in der CI/CD-Pipeline auszuführen und einen grünen Status für Merge-Anfragen zu verlangen. Die Praxis „BDD as a gating mechanism“ wird in der Cucumber-Dokumentation (2024) beschrieben und ist ein Industriestandard.

Leistung von BDD-Tests

BDD-Szenarien in Cucumber werden als instrumentierte Tests auf einem Android-Gerät oder Emulator ausgeführt. Dies ist 10–50 Mal langsamer als normale Unit-Tests auf der JVM. Ein einzelner Abnahmetest kann für eine große Android-Anwendung 20–30 Minuten dauern. Es wird empfohlen, BDD-Tests in einem separaten CI-Job nachts auszuführen, während Unit-Tests bei jedem Push laufen. Diese Strategie gleicht Rückmeldungsgeschwindigkeit und Szenarioabdeckung aus.

Schulung des Teams in Gherkin

Der Übergang zu BDD erfordert Schulungen nicht nur für Entwickler, sondern auch für Analysten und Tester. Gherkin ist eine einfache Sprache, aber das Schreiben guter Szenarien erfordert Übung. Typische Anfängerfehler: zu lange Szenarien (mehr als 10 Schritte), Vermischen von Given-When-Then, Verwendung technischer Begriffe in Geschäftsszenarien. Laut BDD Academy (2024) benötigen Teams durchschnittlich 4–6 Sprints, um Reife im Schreiben von BDD-Szenarien zu erreichen.