BDD: Verhalten in Alltagssprache beschreiben (Given – When – Then)

Kurz: Behaviour-Driven Development beschreibt gewünschtes Verhalten in verständlichen Szenarien nach dem Muster Given – When – Then; die Szenarien sind Anforderung, Dokumentation und automatischer Test zugleich.

Genauer: BDD erweitert TDD: Statt technischer Testnamen schreiben Fachleute, Tester und Entwickler gemeinsam Beispiele in Alltagssprache. So entsteht ein gemeinsames Verständnis, bevor programmiert wird, und die Beispiele laufen später als Tests.

Im Detail

Das Muster: Given – When – Then

Funktion: Warenkorb
  Szenario: Gutschein einlösen
    Angenommen der Warenkorb enthält Artikel im Wert von 50 Euro
    Wenn ich den Gutschein "SOMMER10" einlöse
    Dann beträgt die Summe 45 Euro

• Given (Angenommen): Ausgangslage.
• When (Wenn): Aktion oder Ereignis.
• Then (Dann): erwartetes Ergebnis. Die Sprache dazu heißt Gherkin (.feature-Dateien). Szenarien sind konkret (echte Zahlen, echte Beispiele), nicht abstrakt.

Werkzeuge

Cucumber (viele Sprachen), Behave und pytest-bdd (Python), SpecFlow/Reqnroll (.NET), Cypress/Playwright mit Cucumber. Jeder Satz wird einer Schrittdefinition (Code) zugeordnet, die die Anwendung ansteuert und prüft. Auch ohne Werkzeug ist die Denkstruktur nützlich: Voraussetzung, Aktion, Ergebnis in Tests und Anforderungen.

Drei Amigos und Beispiele

Gute BDD-Praxis beginnt mit dem Gespräch („Drei Amigos“: Fachseite, Entwicklung, Test): Welche Regeln gibt es, welche Beispiele und Randfälle? Offene Fragen werden früh sichtbar, Missverständnisse billig behoben. Die Szenarien dienen als lebende Dokumentation, die nie veraltet, weil sie laufen.

Grenzen und Tipps

• Nicht jedes Projekt braucht Gherkin; Overhead lohnt, wenn Fachleute die Szenarien mitlesen und mitschreiben.
• Szenarien kurz (3 bis 7 Schritte) und ein Verhalten pro Szenario.
• Keine UI-Details („klicke auf Button #3“), sondern Absicht („bestelle den Artikel“).
• Auf E2E-Ebene langsam: nur wichtige Wege; Details als Unit-Tests.
• Kombination: TDD für Code, BDD für Anforderungen.

Siehe auch: Test-Driven Development, Testarten im Überblick, Playwright, Lastenheft und Pflichtenheft