Was ist Behavior Driven Development (BDD)

Behavior Driven Development (bzw. verhaltensgetriebene Softwareentwicklung) ist eine Technik, mit der die in der Softwareentwicklung üblichen Probleme reduziert werden sollen, z.B.

  • Nacharbeiten durch falsch verstandene oder nicht genau spezifizierte Anforderungen
  • Aufbau technischer Schulden
  • Langsame Feedbackzyklen durch fehlende Kommunikation

BDD zielt darauf ab, die Kommunikation zwischen den Teammitgliedern zu verbessern, ein besseres Verständnis des Kunden zu fördern und eine kontinuierliche Kommunikation anhand konkreter Beispiele zu pflegen.

Mit Hilfe konkreter Beispiele wird in BDD beschrieben, wie sich die Software verhalten soll, und zwar noch lange bevor die erste Zeile Code dafür programmiert und erster Test durchgeführt wird. Das schafft nicht nur besseres Verständnis im Team, sondern vermeidet teure Überarbeitungen im späteren Verlauf der Entwicklung durch Missverständnisse.

Die Beispiele (auch Szenarien genannt) werden vor der eigentlichen Programmierung erstellt. Sie werden als eine Art „lebende Dokumentation“ gepflegt, die anfangs als eine Spezifikation herangezogen wird, im weiteren Projektverlauf eine Grundlage für automatisierte Tests während der eigentlichen Entwicklungstätigkeit darstellt und schlussendlich als eine Systemdokumentation herangezogen wird.

Behavior Driven Development

BDD Phasen

BDD kann in zwei Phasen unterteilt werden „Erkundungsphase“ und „Test Driven Development“.

Discovery / Erkundung

Bei der Erkundung geht es darum, dass alle Beteiligten ein einheitliches Verständnis darüber bekommen, wie sich die Software verhalten soll.

Die effizienteste Vorgehensweise dabei ist die Ausarbeitung konkreter Beispiele durch Teammitglieder unterschiedlicher Rollen (wie z.B. Product Owner, Business Analysten, Benutzer, Entwickler und Tester). Dieser Ansatz ist die Grundlage für das „3 Amigos Prinzip„.

Die während der Discovery Phase identifizierten konkreten Beispiel werden als Szenarien mittels der speziellen Gherkin Sprache formuliert und persistiert.

Die vorbereiteten konkreten Gherkin Beispiele( die aus einzelnen Szenarien und Schritten bestehen) agieren als Dokumentation und die Grundlage für die automatisierten Tests für die Softwareentwickler.

 

Test-Driven Development / Testgetriebene Softwareentwicklung

Test Driven Development ist eine Entwicklungsstrategie, bei der die i.d.R. automatisierten Testfälle vor Software-Code entstehen.

Diese Testfälle schlagen natürlich zuerst fehl (rot), da auch die entsprechenden Softwarefunktionen noch nicht existieren. Während der Entwicklung werden diese automatisierten Testfälle dann zur Überprüfung der neuen oder geänderten Softwarekomponente verwendet. Ist die Entwicklung fertig, sollten alle davor geschriebenen Testfälle fehlerfrei durchlaufen (grün).

Im BDD-Umfeld erfolgt die eigentliche Automatisierung flexibel in der Programmiersprache/Testframework der Wahl – wichtig ist nur die Herstellung der Vernüpfung zwischen den jeweiligen Schritten der Gherkin Szenarien und den dazugehörigen Implementierungen der Automatisierung. Zur Abbildung dieser „Verknüpfung“ und zur Testdurchführung anhand der Gherkin Szenarien verwendet man spezielle Testautomatisierungs- bzw. Adapter-Frameworks wie Cucumber.

Zusammenfassung

Bei BDD handelt es sich um eine Entwicklungsstrategie zur Verbesserung der Kommunikation unterschiedlicher Stakeholder und Verringerung von falsch verstandenen Anforderungen und Verhalten von Software.

Zur Abgrenzung zu anderen Begriffen ist es wichtig folgendes festzuhalten:

  • BDD ist keine Teststrategie
  • BDD ist kein Testframework
  • BDD ist kein Testautomatisierungstool
  • Bei BDD / TDD entstehen die Szenarien immer vor dem Code und nicht anschließend. Wird es in der Praxis anders gehandhabt, ist es lediglich eine abstrahierte Testfallbeschreibung und hat nichts mit BDD / TDD Prinzipien zu tun.

Aus diesen Gründen wird BDD häufig auch als Kommunikationsframework bezeichnet.

 

Verwandte Begriffe