Behavior Driven Development einfach erklärt

Früher verbrachte das Qualitätsmanagement Wochen damit, eine fertig entwickelte Software auf ihre Funktionalität zu überprüfen. Heute finden Sie dank automatisierter Tests per Knopfdruck heraus, ob eine komplexe Anwendung ihre Aufgaben ohne Probleme erfüllt. Eine immer beliebtere Technik ist das Behavior Driven Development, kurz BDD. Diese Form der agilen Software-Entwicklung ist aus dem Test Driven Development (TDD) entstanden und wird als dessen logische Erweiterung angesehen. Anders als bei TDD wird bei BDD die jeweilige Software vornehmlich aus der Sicht des Anwenders betrachtet. Ein solcher Ansatz fördert ein ganzheitlicheres Software-Design und erleichtert die Zusammenarbeit zwischen Entwicklern, Qualitätsmanagern und Kunden.

Mit wachsender Komplexität von Software-Anwendungen entstehen auch immer mehr Qualitäts- und Testmanagementmethoden. Nur so lassen sich die Funktionalität einzelner Komponenten zuverlässig überprüfen und Fehler sofort aufspüren. Schon länger bekannt ist die testgeleitete Entwicklung oder Test Driven Development (TDD). Hierbei erstellen Entwickler parallel zur Software passende Unit-Tests oder Systemtests. Beim Designprozess einer Software ist es jedoch durchaus sinnvoll, nicht nur Programmierer, sondern auch Teammitglieder oder Stakeholder ohne technisches Code-Verständnis miteinzubinden. Das Behavior Driven Development (BDD) macht genau das möglich.

Bei der agilen Software-Entwicklung können alle Projekteilnehmer das gewünschte Verhalten der Anwendung definieren, bevor der Programmierer den Quelltext erstellt. Dies geschieht anhand von Beschreibungen, die in für Menschen leicht verständlicher Sprache verfasst werden. Das heißt, dass auch der Kunde, für den die Software entwickelt wird, einen aktiveren Part in der Modellierung übernimmt. BDD fördert also die Zusammenarbeit und sorgt für eine Umverteilung der Verantwortung. Setzen Sie diese Art der Software-Entwicklung richtig ein, vermeiden Sie von vorneherein Missverständnisse und generieren im Idealfall ein qualitativ hochwertigeres Endprodukt.

Wie der Name es schon sagt, orientiert sich Behavior Driven Development an dem Verhalten, das die jeweilige Software zeigen soll. Dank der sogenannten ubiquitären Sprache – was so viel bedeutet wie „allgemein verwendete Sprache“ – können auch Laien bestimmte Verhaltensbeschreibungen erstellen. Die ubiquitäre Sprache stammt aus dem Domain Driven Design (DDD), das sich genau wie das BDD auf die Anwendungsdomäne konzentriert. Beide Ansätzen berücksichtigen alle beteiligten Bereiche bei der Software-Erstellung und verbinden diese unabhängig von Frameworks, Programmiersprachen oder Tools miteinander. Durch die Verwendung einer einheitlichen Sprache ist genau dies möglich.

Trotz allem kommt auch das Behavior Driven Development nicht ganz ohne Tools und Frameworks aus. Denn damit die von Ihnen definierten Testfälle auch in einen ausführbaren Code übersetzt werden können, müssen Sie sich an ein paar Regeln halten. Beschreibungen im BDD werden zum Beispiel nicht im freien Fließtext verfasst. Mithilfe von BDD-Tools wie JBehave, Cucumber oder Behat folgen Sie einer festgelegten Struktur, die eine korrekte Implementierung ermöglicht. Der Umgang mit diesen Tools ist deutlich einfacher als das Erlernen einer klassischen Programmiersprache. Hier erfahren Sie, welcher hierarchischen Struktur Sie beim Behavior Driven Development normalerweise folgen:

• Führen Sie zunächst eine Anforderungsanalyse durch, bei der Sie die Aufgaben, Ziele und Funktionalitäten der Software genau definieren. Stellen Sie sich oder Ihrem Kunden also die Frage, was die Software alles können soll.
• Nachdem Sie alle Funktionalitäten identifiziert haben, werden diese in Form von vordefinierten Szenarien beschrieben. Versuchen Sie, dabei an alle möglichen Situationen zu denken, in denen die Software mit einer bestimmten Antwort reagieren soll.
• Im nächsten Schritt halten Sie die erwartete Antwort für jedes Szenario im „Angenommen-Wenn-Dann“-Schema fest. „Angenommen“ beschreibt die Software vor dem Test, „Wenn“ die Aktion während des Tests und „Dann“ den Zustand der Software nach dem Test.

Je nachdem, welches BDD-Tool Sie verwenden, kann das Vokabular leicht variieren. Statt „Angenommen“ akzeptieren manche Tools auch Formulierungen wie „Gegeben sei“. Solche Werkzeuge sind übrigens für die gängigsten Programmiersprachen wie Java, JavaScript, Python oder Ruby erhältlich.

Stellen Sie sich vor, Sie möchten einen nutzerfreundlichen Onlineshop entwickeln. Hat sich der Kunde einmal in Ihrem Shop registriert, sollen seine Nutzerdaten gespeichert werden. So kann er sich immer wieder einloggen und muss seine persönlichen Daten nicht erneut eingeben. In der weit verbreiteten Gherkin-Sprache, die im BDD-Werkzeug Cucumber zum Einsatz kommt, sieht die richtige Syntax wie folgt aus:

Das obige Beispiel zeigt, dass Sie mithilfe des Zusatzes „Und“ gleich mehrere Bedingungen aufstellen und so Ihre Testfälle so komplexer gestalten können.

Beim Testen einer Software beschäftigt sich Behavior Driven Development mit der „Wie“-Frage. Die Beteiligten wollen wissen, wie sie das Verhalten eines Codes und nicht dessen Implementierung richtig testen können. Bei einem sogenannten Modultest geht es hingegen darum, ob eine einzige Code-Einheit richtig implementiert wird. Dieses Testverfahren beschäftigt sich also mit dem „Was“ und ist ein schneller Weg, einzelne Bugs aufzufinden. Die Frage nach dem „Wenn“ beantwortet das Test-Driven-Development, bei dem es um den Prozess des Ausführens von Tests geht. Dieser Prozess kann auch Modultests oder andere Testmethoden beinhalten.

In der Tabelle unten sind die Vorteile und Nachteile des Behavior Driven Development kurz zusammengefasst:

Obwohl Sie jedes Testverfahren einzeln anwenden können, wird die Qualität Ihrer Software um einiges erhöht, wenn Sie mehrere Testverfahren in Kombination verwenden. Mit BDD definieren Sie dabei die beste Vorgehensweise beim Schreiben von Tests, während Sie mit TDD für eine hohe Testabdeckung sorgen.