BDD

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.

Beispiel, wo sich das tatsächlich auszahlt: Ein Versicherungsprodukt hat eine Regel, dass ein Claim unter 30 Tagen mit gültiger Police automatisch genehmigt wird. Als Gherkin-Szenario geschrieben („Given eine seit 30 Tagen aktive Police, When ein Claim innerhalb des Deckungsfensters eingereicht wird, Then wird er automatisch genehmigt"), können der Product Owner und der Compliance-Prüfer es lesen, bestätigen, dass es der echten Regel entspricht, und den Off-by-One abfangen, bevor er shippt. Dieser Gemeinsame-Sprache-Check ist der ganze Wert von BDD, und er lebt auf der Akzeptanz- und Integrationsebene, wo die Lücke zwischen dem, was Produkt meinte, und dem, was Engineering baute, dort ist, wo Bugs geboren werden.

Es gibt außerdem Wartungskosten, die Teams spät entdecken. Gherkin-Szenarien sitzen auf einer Schicht aus „Step Definitions", Glue-Code, der jede Klartext-Zeile auf echte Testaktionen abbildet. Dieser Klebstoff ist echte Software, die synchron gehalten werden muss, während sich das Produkt ändert, und eine große BDD-Suite mit schlampigen Step Definitions wird zur eigenen Wartungslast, langsam im Lauf und brüchig im Editieren. Der Nutzen (ein Stakeholder kann das Verhalten lesen und unterschreiben) bezahlt diesen Overhead nur, wenn ein Stakeholder sie tatsächlich liest. Wird das Gherkin von Engineers geschrieben, von Engineers gelesen und von niemandem sonst gesehen, zahlst du für eine Übersetzungsschicht ohne Publikum.

Der ehrliche Trade-off und der häufige Fehler: BDD ist kein Ersatz für TDD, es ist eine Schicht obendrauf, und es überall anzuwenden ist der Fehler. „Given zwei Zahlen, When ich sie addiere, Then bekomme ich die Summe" für eine triviale Funktion zu schreiben ist Zeremonie, die kein Business-Stakeholder je liest. Heb dir Gherkin für die Tests auf, die ein Nicht-Engineer wirklich unterschreiben muss, und nutze schlichte Unit-Tests unterhalb dieser Linie. Wie all diese Praktiken ist BDD eine Stufe in einem vernünftigen SDLC und ein Werkzeug für ein echtes Kommunikationsproblem, kein Prozess, den man um seiner selbst willen adoptiert.