Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) ist ein Weg, gemeinsames Verständnis aufzubauen, bevor Code geschrieben wird. Product, Entwicklung und Test (oft die „Three Amigos“ genannt) besprechen ein Feature anhand konkreter Beispiele dafür, wie es sich verhalten soll. Diese Beispiele werden zu Akzeptanzkriterien, und viele Teams automatisieren sie anschließend als ausführbare Spezifikationen mit Tools wie Cucumber, Reqnroll (dem Nachfolger von SpecFlow) oder Behave.

Beispiel

Ein Gespräch über eine Rabattregel wird zu Beispielen wie diesen:

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

Das zweite Szenario ist das wertvolle. Wer es aufschreibt, muss die Frage „über 100 oder ab 100?“ klären, bevor jemand das Falsche baut.

Die drei Praktiken

1. Discovery. Das Feature mit Beispielen erkunden, Grenzfälle und offene Fragen finden.
2. Formulation. Die vereinbarten Beispiele in einer strukturierten, für den Fachbereich lesbaren Form aufschreiben, meist in Gherkin.
3. Automation. Jeden Step an Code binden, sodass die Beispiele als Tests laufen und als lebende Dokumentation dienen.

Häufige Fehler

• BDD als Testtool behandeln. Wer Gherkin erst nach dem Code, allein und ohne Gespräch schreibt, zahlt für eine Übersetzungsschicht, ohne den Nutzen des gemeinsamen Verständnisses zu bekommen.
• Steps auf UI-Ebene. „When I click the button with id submit“ beschreibt die Oberfläche, nicht das Verhalten. Steps sollten ein Redesign überstehen.
• Jedes Szenario über den Browser automatisieren. Eine Geschäftsregel wie der Rabatt oben lässt sich meist schneller und zuverlässiger gegen eine API- oder Service-Schicht automatisieren.
• Riesige Step-Bibliotheken. Hunderte leicht unterschiedliche Step Definitions sind schwer zu warten. Halten Sie das Vokabular klein und fachlich fokussiert.

BDD funktioniert gut, wenn Fachleute die Szenarien tatsächlich lesen und mitgestalten. Schaut außerhalb des Engineerings niemand darauf, ist schlichter Testcode mit guten Namen oft einfacher.