Was ist BDD (Behavior Driven Development)?

Behavior Driven Development (BDD) beschreibt das Verhalten eines Features in einer strukturierten Sprache, die Fachbereich und Entwicklungsteam gleichzeitig verstehen. Das Kernmuster heißt Given-When-Then: Vorbedingung, Aktion, erwartetes Ergebnis. Dieses Format überbrückt unterschiedliche Vorstellungen, dient als Grundlage für automatisierte Tests und hält Anforderungen und Testcode an einem gemeinsamen Ort konsistent.

Das Wichtigste in Kürze

• Die Gegeben-wenn-dann-Syntax von BDD schafft eine gemeinsame Sprache für Fachbereich und Entwicklung, die Missverständnisse bei der Feature-Beschreibung gezielt verhindert.
• Cucumber verbindet lesbare Textbeschreibungen direkt mit ausführbarem Testcode, sodass auch fachfremde Personen den Zweck einer Funktion verstehen, ohne die technische Implementierung zu kennen.
• Testdaten lassen sich in BDD als Datentabellen direkt im Feature-File hinterlegen oder in externe Dateien auslagern, wobei eine unvollständige Datenbasis von Anfang an der häufigste Fallstrick ist.
• Funktionen im Testcode sollten nicht mehr als acht ausführbare Zeilen haben. Wächst eine Funktion darüber hinaus, ist sie ein Kandidat zum Aufteilen.
• BDD-Tests sind deutlich seltener von Anpassungen betroffen als Oberflächentests, was den initialen Mehraufwand bei der Einführung langfristig rechtfertigt.

Was Behavior Driven Development eigentlich beschreibt

Behavior Driven Development (BDD) beschreibt das Verhalten eines Features in einer Sprache, die fachliche und technische Beteiligte gleichermaßen verstehen. Im Zentrum steht nicht der Code, sondern die Frage, was ein Feature tun soll.

Der klassische Ablauf ohne BDD verläuft asymmetrisch: Ein Feature wird formuliert, und zunächst weiß vor allem der Product Owner, worum es geht. Das Entwicklerteam kommt erst später dazu und muss sich erschließen, worauf es ankommt.

BDD setzt davor an. Es zwingt alle Beteiligten, das gewünschte Verhalten so zu beschreiben, dass kein technischer Jargon nötig ist und niemand abdriftet. Das Ergebnis ist eine gemeinsame Grundlage, auf die sich Fachbereich und Technik gleichermaßen beziehen können.

Wie die Given-When-Then-Struktur funktioniert

BDD-Szenarien folgen einer Gegeben-Wenn-Dann-Struktur, die einen Test in drei klare Phasen zerlegt. Das Werkzeug Cucumber nutzt dafür die Sprache Gherkin.

Am Beispiel eines Browser-Tests sieht das so aus:

• Gegeben (Given): Der Browser ist geöffnet, die zu testende Seite ist aufgerufen. Das ist die Ausgangslage.
• Wenn (When): Die Login-Maske wird befüllt und der OK-Button gedrückt. Das ist die Aktion.
• Dann (Then): Bei korrekten Daten erscheint die Seite hinter dem Login, bei fehlerhaften eine Fehlermeldung. Das ist die Erwartung.

Diese Form ist kompakt und trotzdem für jeden lesbar. Ein Entwickler erkennt, was zu tun ist. Jemand aus dem Fachbereich, der sich die Gedanken gemacht hat, versteht ohne technisches Wissen, worum es geht.

Genau diese Überlappung ist der Punkt. Prosatext erzeugt bei jedem Leser ein eigenes Bild, und diese Bilder sind selten identisch. Man merkt den Unterschied oft nicht einmal. Die Given-When-Then-Struktur engt diesen Spielraum ein und räumt Missverständnisse aus dem Weg.

BDD ist Teamarbeit, keine Rollenfrage

Niemand hat das exklusive Recht, BDD-Szenarien zu schreiben. Sowohl der Fachbereich als auch ein Testanalyst kann ein Szenario formulieren, eine feste Zuständigkeit gibt es nicht.

In der Praxis geben oft die Analysten eine erste Fassung vor, und die Tester prüfen sie. Manches lässt sich eins zu eins übernehmen, anderes muss ergänzt oder angepasst werden. Jede Änderung wird mit dem Fachbereich rückgekoppelt: Stimmt das noch, oder ist eine Abweichung entstanden?

Diese Interaktion ist der eigentliche Wert. Das Miteinanderreden und Abstimmen, nicht das Format an sich, sorgt für ein geteiltes Verständnis.

Von der Beschreibung zum ausführbaren Test

Sobald ein Szenario zufriedenstellend formuliert ist, folgt die Implementierung. In Cucumber lassen sich die Schritte aus dem Szenario als Rahmenwerk generieren, das anschließend mit Code gefüllt wird, dem sogenannten Glue Code.

Dieser Glue Code enthält die ausprogrammierte Funktionalität und wird typischerweise von Testautomatisierern oder Entwicklern umgesetzt. Die Given-, When- und Then-Schritte tauchen dabei in den Namen der Funktionen wieder auf, sodass eine Eins-zu-eins-Zuweisung entsteht.

Der Effekt: Selbst jemand aus dem Fachbereich könnte sich den Testcode ansehen und verstehen, welche Funktionalität welchen Schritt abbildet. Wie genau implementiert wurde, ist dabei zweitrangig.

Die fertigen Tests laufen über einen Build-Server, etwa Jenkins. Je nach Teststrategie werden sie ausgeführt, sobald ein Commit eingeht.

Wie BDD mit Testdaten umgeht

Testdaten lassen sich in BDD direkt als Datentabellen im Feature-File hinterlegen. Diese Tabellen werden befüllt und fließen beim Lauf in den automatisierten Test ein. Wer sie pflegt, ob Fachbereich oder Tester, ist offen.

Alternativ können die Daten in ausgelagerten Dateien liegen und von dort angezogen werden. Beide Wege sind möglich.

Wichtig ist die Vorarbeit. Die Testdaten sollten sinnvoll und vollständig sein, bevor man startet. Nachträgliche Erweiterungen sind machbar, ziehen aber oft Umbauten am Test nach sich. Die Testdatenverwaltung verdient deshalb vorab intensive Aufmerksamkeit.

Eine Quelle der Wahrheit über Jira und Build-Server

BDD entfaltet seinen Nutzen erst, wenn Szenarien und Code synchron bleiben. Theoretisch könnte der Fachbereich direkt in Cucumber schreiben, üblich ist das nicht.

Ein praktikabler Weg führt über Jira: Szenarien werden dort hinterlegt und per Plugin in die Feature-Files heruntergeladen oder bei Änderungen wieder hochgeladen. Der Austausch läuft bidirektional und lässt sich über den Build-Server steuern.

Pusht ein Entwickler eine Änderung, zieht der Build-Server die Updates und spielt den aktuellen Stand zurück. Der Fachbereich sieht in Jira immer die neueste Version der Feature-Files.

Das löst ein altes Problem. Mehrere Ablageorte führen schnell zu der Frage, welche Fassung die aktuelle ist. BDD setzt dagegen auf eine Quelle der Wahrheit an einem Ort.

Wo BDD passt und wo die Grenzen liegen

BDD ist flexibel, weil sich in den Glue Code praktisch alles packen lässt. Es ist nicht auf Oberflächentests beschränkt, sondern eignet sich auch für Integrations- und Akzeptanztests, erweiterbar über zusätzliche Libraries.

Sogar manuelle Tests sind möglich. Dann werden die Given-When-Then-Statements vorbereitet, ohne ausführbaren Glue Code dahinter. Sie dienen als einheitliche Dokumentation, die ein manueller Tester abarbeitet.

Eine klare Grenze zeigt sich bei Lasttests. Technisch machbar, aber nicht das richtige Werkzeug. Hier sollte man zu anderen Mitteln greifen, statt BDD zu verbiegen.

Warum der Einstieg mit dem richtigen Testfall beginnt

Der beste Startpunkt ist ein Testfall, der weder trivial noch übermäßig komplex ist. Er sollte eine sichtbare Auswirkung haben, sich aber nicht über Monate ziehen.

Dahinter steht eine ehrliche Erkenntnis: BDD bringt einen Overhead mit. Einen Testfall direkt herunterzucodieren geht schneller, als zusätzlich Feature-Files und eine durchdachte Gherkin-Struktur zu erstellen. Dieser Mehraufwand zahlt sich erst später aus, und das muss von vornherein klar kommuniziert werden.

Diese BDD-Implementierung hat einen gewissen Overhead, der sich erst später auszahlt. Das muss einem bewusst sein, und da muss man von vornherein vorsichtig sein. — Pascal Moll

Wartung: BDD-Tests altern langsamer als Oberflächentests

BDD-Tests müssen wie jeder andere Test gepflegt werden, mit einem zusätzlichen Schritt. Ändern sich die Umstände, müssen auch die Given-When-Then-Statements an den aktuellen Stand angepasst werden.

Die gute Nachricht: Erfahrungsgemäß passiert das deutlich seltener als bei reinen Oberflächentests. Oberflächentests sind spürbar wartungsintensiver.

Ein praktisches Mittel gegen Redundanz ist in Cucumber das Background-Keyword. Damit lassen sich Schritte definieren, die immer am Anfang eines Tests laufen. Das spart duplizierten Code und macht die Szenarien übersichtlicher.

Testcode ist Code: Clean Code zahlt sich aus

BDD-Szenarien erzeugen echten Code, und der will dieselbe Qualität wie Produktivcode. Die Komplexität einer ausprogrammierten Funktion sollte ein gesundes Maß nicht überschreiten.

Eine praktikable Faustregel: Überschreitet eine Funktion acht Zeilen, lohnt der intensive Gedanke, ob sie sich aufteilen lässt. Eine Unterfunktion schafft Übersicht. Diese Heuristik ist leichter anzuwenden als formale Komplexitätsmodelle, bei denen man erst Knoten und Kanten im Code identifizieren muss.

Reviews und gemeinsame Durchsichten helfen zusätzlich. Ein Vier-Augen-Prinzip oder ein Blick des ganzen Teams deckt Optimierungen auf. Fest eingeplante Refactoring-Tage, etwa ein bis zwei Tage gezielt für Codeverbesserung, senken die Komplexität nachweislich.

Wo KI bei BDD heute realistisch unterstützt

KI kann bei BDD assistieren, ersetzt die menschliche Prüfung aber nicht. Es gibt Plugins, die beim Testen Vorschläge machen, etwa Vorhersagen anhand von Daten.

Ein konkreter Ansatz: Aus der Historie eines Tests, also wie oft er erfolgreich war oder fehlschlug, lassen sich Prognosen ableiten. Pusht ein Entwickler Code ins Repository, soll vorhergesagt werden, welche Fehler dieser Code auslösen und welche Tests umfallen könnten.

Naheliegend ist auch, dass KI künftig Given-When-Then-Strukturen vorschlägt. Die eigentliche Arbeit bleibt dann die Prüfung: Passt der Vorschlag, entspricht er der Erwartung, sind kleine Anpassungen nötig? Als Hilfe wird das kommen, als Ersatz für die Beteiligten vorerst nicht.