In der Softwaretechnik ist die verhaltensorientierte Entwicklung (BDD = Behavior Driven Development) ein agiler Softwareentwicklungsprozess. Sie optimiert die Zusammenarbeit zwischen Stakeholder, Entwickler, Qualitätssicherungsexperten und Kundenvertretern in einem Softwareprojekt. Darüber hinaus ermutigt es Teams, Gespräche und konkrete Beispiele zu nutzen, um ein gemeinsames Verständnis dafür zu entwickeln, wie sich eine Anwendung verhalten soll. Es ist aus der testgetriebenen Entwicklung (TDD = Test Driven Development) hervorgegangen.
Die verhaltensgetriebene Entwicklung kombiniert die allgemeinen Techniken und Prinzipien von TDD. Unter Anderem auch mit Ideen aus dem bereichsgetriebenen Design, der objektorientierten Analyse und dem objektorientierten Design, um Softwareentwicklungs- und Managementteams gemeinsame Tools und einen gemeinsamen Prozess für die Zusammenarbeit bei der Softwareentwicklung zur Verfügung zu stellen.
So wie man die Softwareentwicklung sowohl von geschäftlichen Interessen als auch von technischem Verständnis voranbringt, setzt die BDD-Praxis den Einsatz spezieller Softwaretools zur Unterstützung des Entwicklungsprozesses voraus. Obwohl man diese Tools oft speziell für den Einsatz in BDD-Projekten entwickelt, kann man sie als spezialisierte Formen der Tools zur Unterstützung der testgetriebenen Entwicklung betrachten. Diese Tools dienen dazu, die allgegenwärtige Sprache, die ein zentrales Thema von BDD ist, zu automatisieren.
BDD wird weitestgehend durch die Verwendung einer einfachen domänenspezifischen Sprache (DSL = Domain-Specific-Language) mit natürlichen sprachlichen Konstrukten (z.B. deutsch- oder englischsprachige Sätze) erleichtert, mit denen man das Verhalten und die erwarteten Ergebnisse ausdrückt. Testskripte sind seit langem eine beliebte DSLs mit unterschiedlichem Grad an Raffinessen. BDD gilt als effektive technische Praxis, insbesondere wenn der „Problemraum“ des zu lösenden Geschäftsproblems komplex ist.
Wie funktioniert BDD?
Im Grunde genommen besteht Behavior Driven Development aus den folgenden Elementen:
- Starke Einbeziehung der Stakeholder in den Prozess durch sogenannte Outside-In-Softwareentwicklung. Diese ist fokussiert auf die Erfüllung der Anforderungen der Auftraggeber, der Enduser, des Betriebs und von Insidern.
- Textuelle Beschreibung des Verhaltens der Software und von Softwareteilen durch Fallbeispiele. Verwendung genormter Schlüsselwörter zur Markierung von Vorbedingungen, des externen Verhaltens und des gewünschten Verhaltens der Software.
- Automatisierung der Fallbeispiele unter Verwendung von Mock-Objekten zur Simulation von noch nicht implementierten Softwareteilen.
- Sukzessive Implementierung der Softwareteile und dem Ersetzen der Mock-Objekte.
Dadurch entsteht eine automatisiert prüfbare Beschreibung der zu entwickelnden Software, die jederzeit die Richtigkeit der bereits umgesetzten Teile der Software überprüfen lässt.
Wichtig ist hierbei, dass die Beschreibung nicht die Implementierung der Anwendung vorgibt, sondern den Zweck der Anwendung in Form von Anwendungsbeispielen.
Beim Behavior Driven Development werden die Anforderungen an die Software mittels Beispiele, sogenannten Szenarien beschrieben. Üblicherweise wird für die Beschreibung dieser Szenarien ein bestimmtes Format vorgegeben, damit später die automatisierte Überprüfung der Szenarien einfach umzusetzen ist. Eines dieser Formate ist die Beschreibungssprache „Gherkin“. Man kann es auch in verschiedenen Behavior-Driven-Development-Implementierungen verwenden. Diese Sprache gibt es sowohl mit englischen Schlüsselwörtern (Given, When, Then, And, …), deutschen (Gegeben, Wenn, Dann, Und, …) und in weiteren Sprachen. Mehr dazu in meinem Beitrag über Cucumber bzw. Gherkin.
Fazit
Behavior Driven Development (BDD) ist eine agile Softwareentwicklungs-Methode, die sich auf die Zusammenarbeit zwischen Entwicklern, Business Analysten und Kunden konzentriert, um sicherzustellen, dass die erstellte Software den Bedürfnissen der Anwender entspricht. BDD ist eine Erweiterung des Test Driven Developments (TDD) und legt den Schwerpunkt auf die Definition von klaren, verständlichen Anforderungen und Tests, die das Verhalten der Anwendung aus der Perspektive des Nutzers beschreiben. Durch die Verwendung von gemeinsamer Sprache und konkreten Beispielen kann man die Kommunikation zwischen den Stakeholdern verbessern und Missverständnisse vermeiden. Das Ergebnis ist eine höhere Qualität der Software, eine schnellere Markteinführung und eine höhere Kundenzufriedenheit.