METHODE

BDD

Behavior-Driven Development

Tests in einer Sprache schreiben, die der Business-Stakeholder lesen kann. Dann diese Tests passen lassen.

Zuletzt geprüft: 2026-05-24 vonKevin Riedl wiki ↗

Behavior-Driven Development ist TDD mit umgeschriebener Testsprache, sodass Nicht-Engineers sie lesen können. Tools wie Cucumber nutzen ein Given/When/Then-Format, das ein Product Manager unterschreiben kann. Ziel: Tests am Business-Verhalten ausrichten, das sie validieren, statt an der gerade existierenden Implementierung.

Praktisch liegt der Wert am höchsten auf Integration und Akzeptanztest-Ebene, wo die Sprachbarriere zwischen Engineering und Produkt tatsächlich Bugs erzeugt. Auf Unit-Test-Ebene addiert BDD mehr Zeremonie, als es spart."

// FAQ

Häufige Fragen

Häufige Fragen

Selten. Die Erwartung, dass Business-Stakeholder Gherkin pflegen, scheitert fast immer. Realistischer: Engineers schreiben die BDD-Specs, Stakeholder reviewen sie als Spezifikation. Das ist Wert genug; die Mythos-Version ist es nicht.
Kein Entweder-oder. BDD auf Akzeptanz- und Integrations-Ebene, TDD auf Unit-Ebene. BDD bis hinunter zur Unit ist Overkill und produziert mehr Glue-Code als Wert. TDD bis hinauf zur Akzeptanz wird zu test-heavy.
Cucumber für JVM und JavaScript, SpecFlow für .NET, Behave für Python. Tool-Wahl ist sekundär; was zählt, ist ob das Team die Specs wirklich pflegt. Verwaiste BDD-Suites sind schlimmer als keine.