Wissen von A bis Z

Behavior-Driven Development (BDD)

Wenn Ihr Code plötzlich fließend Business-Deutsch spricht, haben Sie wahrscheinlich BDD entdeckt.

Behavior-Driven Development (BDD) ist eine Erweiterung von TDD, bei der die Tests in einer leicht lesbaren, an der Fachsprache orientierten Form geschrieben werden - häufig im Given-When-Then-Stil. Damit sollen Anforderungen, Tests und Code für Fach- und Entwicklungsseite gleichermaßen verständlich werden.

Werkzeuge wie Cucumber (mit der DSL Gherkin), SpecFlow (für .NET) oder JBehave erlauben es, Szenarien in nahezu natürlicher Sprache zu formulieren und mit Implementierungs-Bindings zu verknüpfen. Die Szenarien fungieren gleichzeitig als ausführbare Spezifikation und als Akzeptanztests.

Einsatzzweck ist die enge Zusammenarbeit zwischen Product Ownern, QA und Entwicklung. BDD reduziert das Risiko, dass Anforderungen falsch interpretiert werden, und stellt sicher, dass die Software das tatsächlich erwartete Verhalten zeigt. Es bildet damit eine Brücke zwischen Anforderungsmanagement und automatisierten Tests.

BDD wurde Mitte der 2000er Jahre von Dan North geprägt, der mit JBehave eines der ersten BDD-Frameworks entwickelte. Sein Artikel "Introducing BDD" (2006) positionierte BDD als Antwort auf wiederkehrende Missverständnisse beim Einsatz von TDD und führte das Vokabular von User Stories, Akzeptanzkriterien und Beispielen zusammen.

Liz Keogh, Chris Matts und Gojko Adzic entwickelten BDD später unter Stichworten wie "Specification by Example" weiter. Insbesondere Adzics Buch "Specification by Example" (2011) trug stark dazu bei, BDD aus dem Tester-Werkzeugkasten in den Bereich der Anforderungsanalyse zu verschieben.

Zurück