Behavior Driven Development

Definition und Methodik

Behavior Driven Development, auch bekannt als Specification Driven Development, stärkt die Zusammenarbeit in Softwareprojekten durch die dokumentierte Beschreibung von Aufgaben, Zielen und Ergebnissen der Software in verständlicher Textform. Diese Beschreibungen dienen später als Grundlage für automatisierte Tests. Oft werden „Wenn-dann“-Sätze verwendet, um den Übergang zwischen fachlichen Anforderungen und der Programmiersprache zu erleichtern.

Ein zentraler Bestandteil von BDD ist die fortlaufende Kommunikation im Team und mit Stakeholdern, die durch konkrete Beispiele unterstützt wird. Diese Beispiele werden in Form von Szenarien in standardisierter Sprache wie Gherkin verfasst. Diese Szenarien sind nicht nur am Anfang als Spezifikation nützlich, sondern dienen auch als Grundlage für automatisierte Tests sowie als abschließende Systemdokumentation. Somit begleiten sie den gesamten Entwicklungsprozess als lebende Dokumentation.

Außerdem orientiert sich BDD am gewünschten Verhalten der Software aus Anwendersicht, nicht nur an technischen Anforderungen. Dieser Ansatz ermöglicht eine präzisere und zielgerichtete Entwicklung, da zu jedem Zeitpunkt klar ist, welche Funktionalitäten die Software bieten soll. Die Entwicklung erfolgt meist in kurzen Iterationen, wobei neue oder geänderte Softwarekomponenten durch die bereits definierten Tests kontinuierlich überprüft werden. Dies stellt sicher, dass die Software zu jedem Zeitpunkt den initial festgelegten Anforderungen entspricht und qualitativ hochwertig ist.

Diese Vorgehensweise fördert ein besseres Verständnis der Kundenanforderungen und unterstützt die kontinuierliche Kommunikation zwischen verschiedenen Projektbeteiligten. Ursprünglich 2003 von Dan North entwickelt, entstand in diesem Zuge auch das erste BDD-Framework JBehave, das die Methoden und Prinzipien von BDD technisch unterstützte.

Phasen des BDD

Die Phasen des Behavior Driven Development (BDD) umfassen mehrere Schritte, die aufeinander aufbauen und zusammen eine effektive Softwareentwicklung ermöglichen. Der erste Schritt ist die sogenannte Discovery-Phase, in der das Team ein einheitliches Verständnis des gewünschten Verhaltens der Software erarbeitet. Dazu gehört die Zusammenarbeit von Teammitgliedern aus verschiedenen Rollen, um konkrete Beispiele und Szenarien zu entwickeln. Diese Szenarien werden häufig in der Gherkin-Sprache formuliert, was eine klare und strukturierte Formulierung ermöglicht.

Test-getriebene Entwicklung

In der nächsten Phase wird Test-getriebene Softwareentwicklung (Test-Driven Development, TDD) eingesetzt. Hierbei werden automatisierte Testfälle vor dem eigentlichen Code entwickelt. Diese Testfälle schlagen zunächst fehl (rot), da die entsprechenden Softwarefunktionen noch nicht existieren. Der Code wird anschließend so angepasst und entwickelt, dass er diese Tests besteht (grün). Durch die Verbindung der Gherkin-Szenarien mit den Implementierungen erhalten Entwickler eine klare Vorgabe für die Umsetzung der Tests und deren erfolgreiche Durchführung.

Während dieser Phase kommt es häufig zur Verwendung von Mock-Objekten, um die Szenarien bereits vor der vollständigen Implementierung zu testen. Mock-Objekte simulieren noch nicht umgesetzte Teile der Software, was eine schrittweise Implementierung und Prüfung ermöglicht. Diese Herangehensweise stellt sicher, dass die entwickelten Softwarekomponenten die Anforderungen der Gherkin-Szenarien erfüllen, und hilft dabei, eine verständliche und automatisch prüfbare Softwarebeschreibung zu erstellen.

Umsetzung und Techniken

Bei der Umsetzung von Behavior Driven Development (BDD) steht die Outside-In-Softwareentwicklung im Mittelpunkt, die sich auf die Anforderungen der Auftraggeber, Enduser und anderen Interessengruppen fokussiert. Der Entwicklungsprozess beginnt mit der textuellen Beschreibung des gewünschten Verhaltens der Software in Form von Fallbeispielen. Diese Beispiele nutzen genormte Schlüsselwörter wie „Given“, „When“ und „Then“, um Vorbedingungen, externes Verhalten und das erwünschte Ergebnis zu markieren. Diese Struktur hilft dabei, die Anforderungen klar und verständlich zu formulieren und sie später in automatisierte Tests zu überführen.

Automatisierung und Mock-Objekte

Ein zentrales Element bei der Umsetzung von BDD ist die Automatisierung der Fallbeispiele. Hierbei können Mock-Objekte eingesetzt werden, um Teile der Software zu simulieren, die noch nicht implementiert sind. Dies ermöglicht es, Szenarien frühzeitig zu testen und sukzessive durch tatsächliche Implementierungen zu ersetzen. Dadurch entsteht eine kontinuierlich geprüfte und anpassbare Softwarebeschreibung, die den gesamten Entwicklungsprozess begleitet.

Die konkrete Anwendung von BDD-Tools übersetzt die definierten Testfälle in ausführbaren Code. Diese Tools stellen sicher, dass die entwickelten Funktionen kontinuierlich geprüft werden und den festgelegten Anforderungen entsprechen. Durch diese Methodik wird die Entwicklung nicht nur zielgerichtet und effizient, sondern auch transparent und nachvollziehbar für alle Beteiligten.

Vorteile und Nachteile von BDD

Behavior Driven Development (BDD) bietet zahlreiche Vorteile, die besonders bei der Entwicklung komplexer Softwareprojekte zur Geltung kommen. Einer der größten Vorteile ist die verbesserte Kommunikation und Zusammenarbeit zwischen allen Teammitgliedern und Stakeholdern. Die einheitliche und verständliche Sprache in den Szenarien hilft dabei, Missverständnisse zu vermeiden und ein gemeinsames Verständnis der Anforderungen zu schaffen. Zudem sind BDD-Testfälle flexibel und dienen als lebendige Dokumentation, die jederzeit anpassbar ist und den aktuellen Stand der Softwareentwicklung widerspiegelt.

Weitere Vorteile und Nachteile im Überblick

Ein weiterer Vorteil von BDD liegt in der verstärkten Ausrichtung auf die Bedürfnisse der Endanwender. Der Fokus auf nutzerzentrierte Szenarien sorgt dafür, dass die entwickelte Software benutzerfreundlich und funktional den Erwartungen entspricht. Dieser Ansatz macht BDD auch für Einsteiger ideal, da es eine klare Struktur und nachvollziehbare Beispiele bietet, die den Einstieg erleichtern.

Allerdings hat BDD auch einige Nachteile. Eine der Herausforderungen besteht darin, dass schlecht geschriebene Spezifikationen die Arbeit der Entwickler erschweren können. Um eine effektive Umsetzung zu gewährleisten, ist eine sorgfältige Formulierung der Szenarien unerlässlich. Zudem erfordert die Einbindung mehrerer Parteien und die kontinuierliche Kommunikation mehr Zeit, was die Entwicklungszyklen verlängern kann. Bei bestehenden Projekten und Legacy-Code kann die Umstellung auf einen BDD-Workflow mit einem erheblichen Aufwand verbunden sein.