BDD: Behavior-Driven-Development

Behavior-Driven-Development, kurz BDD, bezeichnet die verhaltensgetriebene Softwareentwicklung, welche eine Methode in den Agilen Softwareentwicklungs-Modellen ist.

Das Test-Driven-Development erfreut sich großer Beliebtheit und die verhaltensgetriebene Entwicklung (englisch Behavior-Driven-Development, BDD) entwickelt diesen Ansatz der testgetriebenen Entwicklung konsequent weiter.

Testautomatisierung ist fester Bestandteil der Softwareentwicklung, insbesondere von Test-Driven-Development (TDD) und Behavior-Driven-Development. Durch BDD können Stakeholder auch ohne technisches Codeverständnis noch früher mit allen Details in den Entwicklungsprozess miteinbezogen werden. Die resultierenden Testfälle aus dem Ansatz von Behavior-Driven-Development fungieren dann als ausführbare Spezifikation und als lebendige Dokumentation.

Was ist Behavior-Driven-Development?

Kernmotivation des Behavior-Driven-Developments ist eine Verbesserung der Kommunikation zwischen Domänenexperten, Testern und Entwicklern. Reibungsverluste beim Informationsaustausch sorgen ohne BDD oft für Missverständnisse. Die Absicht von Endbenutzern, das Verständnis der Entwickler und die Zielsetzung der Qualitätssicherung divergieren auch oft. Diese Probleme hatte Dan North erkannt, als er im Jahr 2003 erstmals den Ansatz des Behavior-Driven-Developments beschrieb. Einige zentrale Ideen prägen beim BDD Ansatz den Entwicklungsprozess:

  • Das gewünschte Verhalten der Anwendung wird anhand von Beispielen („Specification by Example“) beschreiben: „was“ leistet die Software, nicht „wie“ leistet es die Software.
  • Die Beschreibungen werden möglichst früh verfasst, noch vor Beginn der Arbeit am Quelltext der Anwendung.
  • Nicht-technische Projektteilnehmer wie z.B. Endbenutzer oder andere Domänenexperten werden mit einbezogen.
  • Die Verhaltensbeschreibungen werden in menschen-lesbarer Sprache (z.B. Deutsch oder Englisch) verfasst werden und bedienen sich der jeweiligen Fachsprache (der sogenannten ‚ubiquitären Sprache‘).
  • Die Beschreibungen sind lebendige Dokumente und werden entgegen einer klassischen Spezifikation während des Projektes angepasst und erweitert.
BDD im Testing Process

© magele-picture - stock.adobe.com

Vom Behavior zum Testcase

Um später aus den Verhaltensbeschreibungen Testfälle ableiten zu können werden die Testfälle beim BDD nicht im völlig freien Fließtext verfasst. Stattdessen folgen die Texte idealerweise einer hierarchischen Struktur:

  1. Zunächst werden verschiedene gewünschte Funktionalitäten der Software identifiziert – was soll die Software können? Beispiele sind z.B. ‚Kunden anlegen‘ oder ‚Berichte drucken‘.
  2. Jede identifizierte Funktionalität wird dann in verschiedenen Situationen oder Szenarien beschrieben; beispielsweise ‚Einen ersten Kunden anlegen‘ oder ‚Bericht drucken ohne konfigurierten Drucker‘.
  3. In jedem Szenario wird das erwartete Verhalten in einem Angenommen-Wenn-Dann Schema beschrieben, z.B. ‚Angenommen die Kundenliste ist leer, Wenn ich einen neuen Kunden anlege, Dann wird in der Kundenliste ein Eintrag angezeigt‘.

Wichtig ist beim Behavior-Driven-Development, dass diese Beschreibungen nicht die Implementierung einer Funktionalität vorwegnehmen.

Anstatt beispielsweise eine konkrete Testfallbeschreibung wie folgende …

Wenn die Schaltfläche 'Suchen' angeklickt wird
Dann muss der Text ABC in das Eingabefeld eingegeben werden

… ist eine abstraktere Testfallbeschreibung wie folgende beim BDD Ansatz besser:

Wenn das Formular zur Kundensuche geöffnet wird
Dann muss die Kunden-ID ABC angegeben werden können

Die abstraktere Beschreibung beim BDD hat gleich mehrere Vorteile:

  • Die Beschreibungen können früh verfasst und von Endbenutzern oder Auftraggebern auf Plausibilität geprüft werden.
  • Der Lösungsraum in dem sich die Entwickler bewegen wird nicht eingeschränkt: Erfolgt das Öffnen eines Formulars via Klick? Oder Tastendruck? Oder beidem? Wie etwas geschieht, wird in den Beschreibungen nicht eingegrenzt.
  • Die Wartbarkeit der beschriebenen Funktionalitäten wird erhöht: Selbst bei gravierenden technischen Änderungen an der Software bleibt das erwartete Verhalten konstant.

Um dieses Potential zu realisieren ist es häufig empfehlenswert, die Beschreibungen zusammen mit einem erfahrenen Moderator oder Berater zu verfassen. Seine Aufgabe ist es, darauf zu achten, dass die Beschreibungen nicht zu detailliert ausfallen: Die Tests sollen so präzise wie nötig, nicht so präzise wie möglich ausfallen. Welches Netzwerkprotokoll oder GUI Technologie eingesetzt wird sollte an dieser Stelle keine Rolle spielen. Wichtig ist, dass am Ende alle Beteiligten das gleiche mentale Modell des gewünschten Verhaltens mit an den Schreibtisch nehmen.

Gherkin: Strukturierte Verhaltensbeschreibungen als Basis für Behavior-Driven-Development

Als Format für die strukturierte Beschreibung des erwarteten Verhaltens, erfreut sich die Sprache Gherkin großer Beliebtheit. Ursprünglich vom Open-Source Test-Framework „Cucumber“ eingeführt, wird es mittlerweile von vielen anderen Testwerkzeugen unterstützt. Die Sprache ähnelt einem Fließtext sehr, ist aber gleichzeitig leicht von einem Computer zu interpretieren.

Ein beispielhafter Testfall für ein Programm zur Adressverwaltung könnte in der Gherkin Sprache so aussehen:

Funktionalität: Adressen hinzufügen
    Szenario: Eine erste Adresse hinzufügen
        Angenommen die Adressbuch Anwendung wurde gestartet
        Wenn ich ein neues Addressbuch anlege
        Und das Formular zum Anlegen eines neuen Eintrags öffne
        Und einen Eintrag für 'Max Mustermann', 'max@mustermann.com', '01234/56789' anlege
        Dann sollte die Adressbuch Anwendung 1 Eintrag anzeigen

Die relevanten BDD-Schlüsselwörter sind hier fett markiert. Im gegebenen Beispiel handelt es sich um einen deutschen Text, Gherkin erlaubt allerdings viele andere Sprachen. Auf Englisch wären z.B. ‚Feature‘, ‚Scenario‘ oder ‚Given‘ Schlüsselwörter. In jedem Fall folgen die Gherkin Dokumente einer festen Struktur:

  1. In der ersten Zeile wird die zu beschreibende Funktionalität benannt: der Name (hier: „Adressen hinzufügen“) ist frei wählbar, wichtig ist das Schlüsselwort „Funktionalität“.
  2. Danach wird das Verhalten der Funktionalität in verschiedenen Szenarien in Form von Beispielen beschrieben. Die einzelnen Szenarien werden typischerweise eingerückt – das ist eine Frage der Lesbarkeit und macht keinen funktionalen Unterschied. Ein Szenario wird durch eine Zeile die mit dem Wort ‚Szenario‘ beginnt eingeleitet.
  3. Die einzelnen Szenarien werden beim Behavior-Driven-Development üblicherweise im Angenommen-Wenn-Dann Schema beschrieben. An dieser Stelle erlaubt die Gherkin Sprache viele Synonyme (z.B. ‚Gegeben sei‘ statt ‚Angenommen‘).

Der eigentliche Mehrwert dieser Struktur erschließt sich im Zusammenspiel mit Softwarewerkzeugen, welche solche BDD Beschreibungen direkt verarbeiten können. Ohne die Beschreibungen anzupassen, können geeignete Testwerkzeuge die einzelnen Schritte direkt mit entsprechenden Aktionen verknüpfen. Die Aufgabe der Tester es ist somit, einem Schritt wie …

Wenn ich ein neues Addressbuch anlege

… eine konkrete Benutzeraktionen und Verifikationen zuzuweisen. Zum Beispiel einen Klick auf eine Schaltfläche gefolgt von einer Überprüfung, ob der erwartete Dialog angezeigt wird. Auf diese Weise werden die mit dem Domänenexperten verfassten Beschreibungen zu einer ‚ausführbaren Spezifikation‘. Fehlerhaften Interpretationen durch Entwickler oder Testern kann somit durch Behavior-Driven-Development effektiv vorgebeugt werden.

Aus dem Anspruch der extrem frühen Testerstellung ergibt sich die Frage: Wie können Tests ausgeführt werden, wenn es noch keine zu testende Anwendung gibt? Dazu sind zwei Ansätze denkbar:

  • Es können sogenannte ‚Mock Objekte‘ definiert werden: Diese simulieren noch nicht implementierte Teile der Software und fungieren als Platzhalter.
  • Im Testwerkzeug selbst werden mit einem Schritt keine spezifischen Schritte assoziiert; stattdessen wird eine Meldung wie ‚To Do‘ im Testprotokoll vermerkt.

Toolsupport für Behavior-Driven-Development

Ein BDD-basierter Ansatz ist prinzipiell für alle Ebenen der Testentwicklung denkbar, bietet sich allerdings primär für Akzeptanztests an. Idealerweise werden Testwerkzeuge mit dedizierter Unterstützung für den BDD Ansatz eingesetzt. Neben einigen kommerziellen Tools existiert auch eine ganze Reihe von Open Source Tools wie z.B. behaveCucumber oder JBehave. Insbesondere Cucumber erfreut sich großer Beliebtheit im Open Source Lager. Um einen Eindruck des BDD-basierten Testens zu erhalten, betrachten wir zwei konkrete Fallbeispiele im Einzelnen. Dazu haben wir zwei Vertreter der Testwerkzeuge mit dedizierter Unterstützung für Gherkin Skripte exemplarisch gewählt:

Zum einen das kommerzielle Tool Squish. Squish wird zur Entwicklung von portablen, plattform-übergreifenden Entwicklung von funktionalen GUI Tests eingesetzt. Mit Hilfe einer IDE werden alle populären GUI Technologien sowie mehrere offene Skriptsprachen (Python, JavaScript, Ruby, Perl, Tcl) zur Implementierung der Tests unterstützt.

Daneben wird das Framework Cucumber betrachtet. Ursprünglich für das Ausführen von BDD Tests in der Programmiersprache Ruby gedacht, unterstützt Cucumber mittlerweile eine ganze Reihe von anderen Programmiersprachen wie z.B. Java, PHP oder Lua. Cucumber Tests werden typischerweise für Unit- oder Integrationstests verwendet.

Fallbeispiel BDD 1: Funktionaler GUI Test mit froglogic Squish

Im Jahre 2003 erstmals veröffentlicht, erlaubt Squish das Entwickeln portabler funktionaler GUI Tests. Die 2015 veröffentlichte Version 6.0 führte die dedizierte Unterstützung für BDD Testfälle ein.

Squish bietet eine bequeme IDE, in die der eben erwähnte Gherkin Text direkt eingefügt werden kann:

Squish IDE mit integriertem Gherkin Editor für Behavior-Driven-Development

Tests können dann aufgezeichnet werden, wobei der aktuell zu implementierende Schritt in einer sogenannten ‚Control Bar‘ hervorgehoben wird. Ein Klick auf das Häkchen neben dem aktuellen Schritt zeigt dem Tool an, dass nun die dem Schritt entsprechenden Aktionen ausgeführt wurden.

Controlbar der Squish IDE beim Aufzeichnen eines BDD Tests

Auf den Aktionen basierend erzeugt das Werkzeug daraufhin Skriptcode in einer der üblichen Skriptsprachen (hier: Python); eine im Programm integrierte Skriptbibliothek sorgt mittels sogenannter ‚Python Decorator‘ für die Assoziation der BDD Schritte mit dem zugehörigen Skript Code.

import names

@Given("die Adressbuch Anwendung wurde gestartet")
def step(context):
    startApplication("SquishAddressBook")

@When("ich ein neues Addressbuch anlege")
def step(context):
    mouseClick(waitForObject(names.address_Book_Untitled_New_NSToolbarItem))

@When("das Formular zum Anlegen eines neuen Eintrags öffne")
def step(context):
    mouseClick(waitForObject(names.address_Book_Untitled_Add_NSToolbarItem))

Bei Ausführung der Tests über die IDE (eine Ausführung auf der Kommandozeile ist ebenso möglich) werden die Resultate direkt im Gherkin Editor eingeblendet:

Behavior-Driven-Development Beispiel: Squish IDE zeigt Testresultate direkt im Gherkin Editor an

Fallbeispiel BBD 2: API Test mit Cucumber

Im Jahre 2008 von Aslak Hellesøy gestartet, ist Cucumber ein Urgestein unter den Open Source Testframeworks mit Behavior-Driven-Development Unterstützung und hat nichts von seiner Popularität eingebüßt. Es ist das Tool, welches die ‚Gherkin‘ Sprache ursprünglich einführte. Tests in Cucumber wurden ursprünglich in Ruby geschrieben, mittlerweile jedoch gibt es viele Ableger um Tests z.B. In Java, PHP oder Lua zu definieren. Cucumber selbst implementiert keine APIs um beispielsweise Last-, API- oder GUI-Tests zu implementieren, sondern baut stattdessen auf existierende Bibliotheken auf um beispielsweise eine REST API zu testen.

Eine beispielhafte Spezifikation des erwarteten Verhaltens der REST API einer Benutzerverwaltung könnte BDD getreu wie folgt aussehen:

Funktionalität: Benutzer abfragen

    Die REST Schnittstelle erlaubt es, die Informationen mehrer oder einzelner Benutzer
    abzufragen.

    Szenario: Alle Benutzer abfragen
        Angenommen die Liste aller Benutzer wird abgefragt
        Dann sollten nur die erste Seite der Liste zurückgegeben werden
        Und auf der Seite sollten maximal drei Einträge aufgeführt sein

    Szenario: Einen unbekannten Benutzer abfragen
        Angenommen die Information zu einem Benutzer mit unbekannter ID wird abgefragt
        Dann sollte die HTTP Antwort 404 zurückgeliefert werden
        Und der Inhalt der Antwort sollte ein leeres Objekt sein

Auch hier wird in der ersten Zeile mittels eines speziellen Kommentars die verwendete Sprache deklariert. Dieses Dokument ist direkt über das ‚cucumber‘ Programm ausgeführt werden. Da bisher keine Implementierung der einzelnen Schritte definiert wurde, passiert natürlich nichts. Stattdessen gibt Cucumber den Quelltext eines Programmgerüsts aus, welches als Basis für eine eigene Implementation genutzt werden kann:

Cucumber Ausgabe bei Ausführung eines BDD Tests ohne Implementierung

Nachdem dieses Gerüst mit Leben gefüllt wurde kann das Gherkin Dokument erneut ausgeführt werden. Durch die Erkennung der einzelnen Szenarien und Schritte kann Cucumber einzelne Szenarien ausführen. Wie z.B. in Folgendem:

Cucumber Ausgabe eines einzelnen erfolgreichen Behavior-Driven-Development Szenarios

Fazit: Behavior-Driven-Development braucht Disziplin, abstrahiert dann aber hervorragend das erwartete Verhalten

Der BDD Ansatz stellt eine ausdrucksstarke Abstraktionsebene dar, welche insbesondere bei Tests auf oberster Ebene wie z.B. GUI Tests seine Stärken ausspielt. Erwartete Verhalten können schon früh mit Domänenexperten und Kunden beschrieben werden, auch nicht-technische Projektteilnehmer können so von Anfang an involviert werden. Durch entsprechende Software-seitige Unterstützung werden diese Verhaltensbeschreibungen dann sehr lebendig und fungieren als ausführbare Spezifikation. Diese Dokumente bleiben auch weiterhin lebendig und können im Projektverlauf um neue zu testende Szenarien sowie zusätzliche Funktionalitäten erweitert werden.

Behavior-Driven-Development braucht Disziplin Icon

© Vlad Kochelaevskiy - stock.adobe.com

Sowohl die Gherkin Sprache wie auch die verwendeten Testtools bieten noch viele zusätzliche Funktionalitäten, die hier nicht präsentiert wurden. So ist beispielsweise ein Datengetriebenes Szenario mithilfe von Tabellen möglich. Ferner können verschiedene Schritte, die im Prinzip das Gleiche tun, über Platzhalter identifiziert werden.

Um diese Vorteile zu nutzen sind neben den passenden Testtools aber vor allen Dingen Disziplin beim Verfassen der Gherkin Dokumente gefragt. Implementationsdetails nicht vorweg zu nehmen erfordert Disziplin. Gleichzeitig müssen die formulierten Schritte präzise genug sein, um die gewünschte Verhaltensweise ausreichend genau zu beschreiben. Ansonsten zerfällt die Abstraktion und Gherkin Dokumente würden somit klassischen Testskripten mit etwas lesbarerer Syntax entsprechen, womit der Sinn und Zweck von Behavior-Driven-Development verfehlt wäre.

 

Anmerkung der Redaktion:

Wir danken der froglogic GmbH herzlich für diesen hervorragenden Artikel über Behavior-Driven-Development.
Bei Fragen zu BDD, Squish oder Gherkin hinterlassen Sie sehr gerne einen Kommentar oder melden sich per Mail direkt bei dem Autor oder unserer Board-Redaktion. Gefällt Ihnen der Artikel, würdigen Sie dies sehr gerne über einen Social-Share.

Fanden Sie den Artikel hilfreich?
[Gesamt: 13 Durchschnitt: 5] -
Share it,
if you like it

Latest Comments

  1. Jan September 25, 2018
  2. Georg Mai 11, 2021

Leave a Reply