Behavior Driven Development
Copyright © Shutterstock / Alexander Supertramp
Bei der agilen (beweglichen) Softwareentwicklung stehen selbstorganisierte Teams sowie inkrementelle und iterative Vorgehensweisen im Vordergrund. Durch die moderne Art von Softwareentwicklung soll der Entwicklungsprozess schlanker und flexibler werden als bei den klassischen Modellen. Eine der wichtigsten Techniken, die im Rahmen der agilen Softwareentwicklung zum Einsatz kommt, ist die verhaltensgetriebene Softwareentwicklung.
Inhaltsverzeichnis
Definition
Das Behavior Driven Development (BDD) wird oftmals als anforderungsgetriebene Softwareentwicklung (Specification Driven Development) (SDD) bezeichnet. Bei dieser agilen Softwareentwicklungstechnik steht die Zusammenarbeit zwischen dem Qualitätsmanagement und der Business-Analyse im Vordergrund und diese soll in den Softwareentwicklungsprojekten gestärkt werden.
Behavior Driven Development – Geschichte und Bedeutung
Das Behavior Driven Development wurde zum ersten Mal im Jahr 2003 von Dan North in Form einer Antwort auf die testgetriebene Entwicklung öffentlich beschrieben. Seit dieser Zeit hat sich die verhaltensgetriebene Softwareentwicklung nach und nach weiter entwickelt. Dan North hat das BDD nicht nur erstmals erwähnt, er hat das erste Framework (Programmiergerüst in der Softwaretechnik) mit dem Namen “JBehave” für die praktische Umsetzung des Behavior Driven Development entwickelt.
Das BDD zeichnet sich dadurch aus, dass bereits während der Analyse der Anforderungen die späteren Ziele, Aufgaben und die Ergebnisse der jeweiligen Software in einer festgelegten Textform notiert werden. Auf Basis dieser Anforderungen werden im Anschluss daran die automatisierten Tests durchgeführt, damit das Programm im Hinblick auf eine korrekte Implementierung umfangreich getestet werden kann.
Die Anforderungen an die Software werden in der Regel in sogenannten “Wenn-dann-Sätzen” festgehalten und diese basieren auf der ubiquitären Sprache vom Domain-driven Design. Dadurch soll ein Übergang von der menschlichen Sprache der Definition der jeweiligen Anforderungen zu der technischen Programmiersprache deutlich erleichtert werden. Dank dieser Erleichterungen sollen die Anforderungen in der Programmiersprache besser umgesetzt werden können.
Beim Behavior Driven Development werden im direkten Vergleich zu herkömmlichen Modellen keine austauschbaren Testmethoden definiert, stattdessen wird das Verhalten einer Software konkret beschrieben. Dadurch können alle Beteiligten an den Projekten den Sinn und Zweck der Tests ohne Probleme nachvollziehen. Die Fokussierung auf das individuelle Verhalten von einem Programm ist im Hinblick auf den Geschäftswert von Vorteil, den eine entwickelte Software für den Auftraggeber bzw. das Unternehmen darstellt. Macht eine Webanwendung oder eine Software in der Praxis nicht genau das, was sie tun soll, so sind die geschäftlichen Ziele von einem Unternehmen nicht erreicht. Tut das Programm genau das, was es soll, so sind die Geschäftsziele entweder teilweise oder vollständig erreicht.
Aus diesem Grund profitieren vom modernen Behavior Driven Development nicht nur die Entwickler von einer Software, sondern alle beteiligten Personen. Durch den direkten Fokus auf das jeweilige Verhalten von einem Programm entsteht ein direkter Bezug zu den jeweiligen inhaltlichen Merkmalen der Softwareentwicklung. Ein Programmierer weiß genau, was seine Software in der Praxis tun soll und hält ihre Funktionen ausführlich in den jeweiligen Anforderungskatalogen fest. Selbstverständlich hat ein Entwickler einen direkten und privilegierten Zugang zu der Material. Diesen Zugang haben andere Beteiligte an dem Projekt, wie beispielsweise die Qualitätssicherung oder das Projektmanagement nicht.
Tipp
Durch das Behavior Driven Development wird es für alle beteiligten Personen deutlich einfacher zu verstehen, was eine Software leisten soll und welche Voraussetzungen sie im Praxiseinsatz erfüllen muss. Die Programmierung und alle Arbeiten an einem Programm lassen sich mithilfe der ubiquitären Sprache von jeder beteiligten Person bis ins kleinste Detail nachvollziehen.
Die Architektur des Programms besitzt zudem einen direkten Bezug zu der Domäne, in der die Software später laufen soll. Das Domain-Driven Design ist vollkommen unabhängig von Werkzeugen, Frameworks und allen gängigen Programmierparadigmen. Dennoch wird das Design oftmals im direkten Zusammenhang mit der objektorientierten Programmierung eingesetzt.
Aus welchen Elementen besteht das Behavior Driven Development?
Als eine wichtige Technik, die im Rahmen der agilen Softwareentwicklung zum Einsatz kommt, besitzt das Behavior Driven Development spezielle Eigenschaften. Im direkten Vergleich zu herkömmlichen Entwicklungstechniken gibt es gleich mehrere Vorzüge und das BDD schafft zusätzliche Möglichkeiten. Unter dem Strich ist es für alle Beteiligten von Vorteil, wenn das Behavior Driven Development zum Einsatz kommt.
Grundsätzlich besitzt das Behavior Driven Development besondere Eigenschaften, besteht aus mehreren Elementen und folgt einem bestimmten Ablauf. Eine wichtige Rolle spielt das TDD (Test Driven Development). Bei der testgetriebenen Entwicklung geht es vor allem darum, dass sich die Entwickler während der Implementierung einer Software sich mit ihren eigenen Tests unterstützen und treiben lassen können.
Besonders wichtig ist die Outside-In-Softwareentwicklung, denn die Tests sollen von außen über eine öffentliche Schnittstelle erfolgen. Aufgrund dessen werden alle Beteiligten stark mit in den Entwicklungsprozess vom Behavior Driven Development einbezogen und können die einzelnen Entwicklungsschritte leichter nachvollziehen. Das Ziel ist das Erfüllen der jeweiligen Anforderungen der späteren Nutzer oder der Auftraggeber.
Durch praktische Fallbeispiele wird das Verhalten einer Software samt dem jeweiligen Verhalten der einzelnen Softwareteile textuell beschrieben. Zum Einsatz kommen genormte Schlüsselwörter und mit diesen werden alle Vorbedingungen, das gewünschte und das externe Verhalten gut sichtbar markiert. Die praktischen Fallbeispiele werden mittels speziellen Mock-Objekten (Attrappen in der Softwareentwicklung) automatisiert und können zur Simulation der noch nicht integrierten Softwareteile verwendet werden.
Im Anschluss daran erfolgt eine sukzessive Implementierung aller bisher noch nicht integrierten Teile. Zu diesem Zweck werden alle bisherigen Attrappen durch die jeweiligen Softwareteile ersetzt. Durch diesen Prozess entsteht eine leicht prüfbare Beschreibung der Software und anhand dieser lässt sich zu jeder Zeit überprüfen, ob die umgesetzten Softwareteile korrekt sind. Besonders wichtig bei diesem Vorgang ist es, dass die jeweilige Beschreibung nicht für die Implementierung einer Anwendung verwendet wird, sondern dem Zweck der jeweiligen Anwendung dient.[/accordion]
Welche Werkzeuge kommen zum Einsatz?
Beim Behavior Driven Development kommen, wie bei jeder anderen Art der Softwareentwicklung, verschiedene Werkzeuge (Frameworks) zum Einsatz. Diese Werkzeuge werden für das jeweilige Verhalten in verschiedenen Szenarien programmiert und eignen sich in der Regel für eine bestimmte Programmiersprache. Zu den bekanntesten Werkzeugen im Bereich vom Behavior Driven Development gehören Java sowie JavaScript, FIT (Framework for Integrated Test), RBehave, JBehave, FitNesse, Cucumber für Ruby und Concordion für Java.
Die Umsetzung der Attrappen (Mock-Objekte) erfolgt entweder manuell von Hand oder über spezielle Frameworks wie EasyMock oder Mockito. Die Objekte werden nicht nur zum Ersetzen von Teilen der Software benötigt, sie sind auch bei der direkten Entwicklung der Tests hilfreich.
Praktische Beispiele für das Behavior Driven Development
Die Anforderungen an eine Software werden mittels Szenarios beschrieben. In der Regel erfolgt diese Beschreibung in einem bestimmten Format. Dadurch lässt sich eine automatisierte Überprüfung der Beispiele leicht umsetzen. Eines der gängigen Formate beim Behavior Driven Development ist die bekannte Beschreibungssprache Gherkin. Diese kann sowohl mit deutschen (gegeben, wenn, dann, und) als auch mit englischen Schlüsselwörtern (given, when, then, and) erfolgen. Weitere Sprachen sind ebenfalls möglich. Die praktische Umsetzung lässt sich anhand folgendem Beispiel verdeutlichen:
Szenario: Ein zurückgegebenes Produkt kehrt wieder in das Lager zurück
- Gegeben ist, dass ein Kunde einen schwarzen Rucksack gekauft hat
- Und es befinden sich 5 schwarze Rucksäcke im Lager
- Wenn der Käufer den Rucksack zurückgibt, erhält er eine Gutschrift
- Dann Befinden sich 6 schwarze Rucksäcke im Lager
Dieses Beispiel illustriert den spezifischen Verhaltensaspekt einer Software. Alle Beteiligten an einem Projekt sollten sich fragen, ob das Ergebnis von einem Szenario stets in einem zu vorgegebenen Kontext auftritt. Ist dies der Fall, so lassen sich weitere Beispiele zur Klärung der jeweiligen Anforderung erstellen.
Anhand des oberen Beispiels könnte ein Beteiligter mit Fachwissen erkennen, dass der zurückgegebene Rucksack nur in das Lager kommt, wenn er keine Fehler hat. Entsprechend seines Wissens müsste das Beispiel ergänzt werden. Mit den Schlüsselwörtern gegeben, wenn, dann, und lassen sich die Szenarien beim Behavior Driven Development verdeutlichen, sie sind jedoch keine Pflicht.
Sie haben noch Fragen?
