Kurzfassung
BDD ist eine kollaborative Entwicklungsmethodik, die die Lücke zwischen technischen Tests und Geschäftsanforderungen überbrückt, indem Verhalten in einer gemeinsamen Sprache ausgedrückt wird, die Entwickler, Tester und Produkt-Stakeholder verstehen.
Was ist BDD?
Von Dan North als Weiterentwicklung von TDD eingeführt, konzentriert sich BDD auf die Beschreibung des Verhaltens eines Systems statt auf das Testen seiner Implementierung. Szenarien werden in einer strukturierten natürlichen Sprache geschrieben – typischerweise Gherkins Given/When/Then-Syntax – die alle Teammitglieder lesen und zu der alle beitragen können.
Diese Szenarien dienen sowohl als Dokumentation als auch als ausführbare Tests. Tools wie Cucumber (Java, Ruby), Behave (Python) und RSpec (Ruby) parsen Gherkin-Szenarien und ordnen sie Step Definitions zu, die die Anwendung steuern.
BDD fördert Gespräche zwischen Entwicklern, QA und Geschäfts-Stakeholdern (die "Three Amigos") vor Beginn der Implementierung, um Missverständnisse und Nacharbeit zu reduzieren.
Warum ist BDD relevant?
- Gemeinsames Verständnis: Gherkin-Szenarien schaffen eine einzige Informationsquelle, die sowohl für das Geschäft als auch für technische Teams lesbar ist
- Lebende Dokumentation: Bestandene Szenarien beweisen, dass Features wie spezifiziert funktionieren; sie entwickeln sich mit der Codebasis weiter
- Zusammenarbeit: Three-Amigos-Sessions decken Unklarheiten früh auf und reduzieren kostspielige späte Fehler