Ausführbare Spezifikationen (und eine Portion BDD)

Diesen Begriff hat Dan North schon 2006 geprägt, als Reaktion auf immer wiederkehrende Probleme mit Test-driven Development. Sein einfacher, aber genialer Vorschlag zur Verbesserung von TDD lautete: „Die Namen von Testmethoden sollten umgangssprachliche Sätze sein“. In Kurzform: BDD versucht, Test-driven Development, einige Aspekte von Domain-driven Design sowie Techniken des automatisierten Akzeptanztests miteinander zu verbinden, um Entwicklungsteams, Fachleute und andere Stakeholder mit einer gemeinsamen Sprache auszustatten.

Klingt erstmal wie reinstes Marketingdeutsch – enthält aber viel Wahrheit. Unsere Recherchen zum aktuellen Stand von BDD und den zugehörigen Tools haben bei uns einen sehr positiven Eindruck hinterlassen.

In BDD geht’s um Spezifikation

Fangen wir einmal vorne an. Wir wollen doch alle (Entwicklungsteams inklusive ArchitektInnen, Product Owner, Requirements Engineers, Tester und andere) zuerst einmal verstehen, was unser System denn genau tun soll. Natürlich iterativ und in kleinen Portionen, weil sich viele Dinge und Erkenntnisse erst während der Entwicklung ergeben. Dieses „Was-das-System-genau-tun-soll“ bildet den Kern von BDD. Es geht um das Verhalten des Systems, um das genaue Verständnis, was die wesentlichen Stakeholder denn von dem System erwarten und warum. Es geht nicht(!) primär um automatisch ausführbare Testfälle, sondern eben erstmal um ein angemessen präzises Verständnis von Anforderungen – was auch der Grund ist, weswegen wir das Thema in dieser Kolumne aufgreifen.

BDD arbeitet Top-Down

Ähnlich wie wir das zu Beginn unserer Req4Arcs-Kolumne vorgeschlagen haben, fordert auch BDD, bei der Spezifikation mit einer strategischen Zielsetzung (auch Vision genannt) zu beginnen, damit wir als Entwicklungsteam wissen, wohin die Reise insgesamt führen soll [1]. Anschließend brechen wir beim BDD diese Anforderungen auf sogenannte Features herunter, die wir dann wiederum durch Beispiele konkretisieren. Erst diese Beispiele versuchen wir dann bei Bedarf zu automatisieren. John Ferguson Smart [2] hat dafür eine sehr feingranulare Hierarchie vorgeschlagen, die Sie (auszugsweise)in Abbildung 1 finden.

Abb. 1: Hierarchie von Anforderungen in BDD (nach [2])

Abb. 2: Beispiel für Impact-Map nach [2]

An dieser Stelle interessieren uns die eher konkreten Teile dieser Pyramide beginnend bei den sogenannten Features. Die zu finden, stellt manchmal schon eine ordentliche Herausforderung dar, bei deren Überwindung uns unter anderem die Methode Impact Mapping (Kasten: „Impact Map“) helfen kann. Außerdem haben wir in den zurückliegenden Folgen mehrmals über funktionale Anforderungen geschrieben – auch da werden Sie fündig. Gehen wir also hier optimistisch davon aus, dass Sie mit Ihrer Lieblingsmethodik vernünftige und zum Gesamtziel beitragende Features finden. Die priorisieren Sie natürlich anhand der bekannten Geschäftsziele – aber das kennen Sie als treue LeserIn unserer Kolumne ja bereits. Die offene Frage lautet: „Wie können wir die jetzt ausführbar machen?“

Konkretisierung nach Schema F

Unsere Features werden oftmals noch als relativ abstrakte Wünsche oder Zielvorstellungen ausgedrückt, insbesondere ohne Implementierungsdetails. Diese fügen wir in den Verfeinerungen (üblicherweise Stories oder Szenarien genannt) hinzu, dann jeweils mit klar formulierten Akzeptanzkriterien. Letzteres klingt schon ein wenig nach Automatisierung, besonders wenn wir den BDD-Vorschlägen folgen und unsere Stories oder Beispiele gemäß der einfachen Syntax der Sprache Gherkin (Kasten: „Gherkin kompakt“) formulieren. Gherkin-Szenarien bestehen aus dem Dreisatz Given-When-Then. Ein Beispiel inklusive dem dazugehörigen Feature finden Sie in Listing 1.

Feature: Team Scoring
  Teams starts with zero score
  Correct answer gets points depending on how difficult it is
Scenario: Score starts at zero
  Given I register a team 
  Then my score is zero
Scenario: Correct easy answer scores 10
  Given I register a team
  When I submit a correct easy answer
  Then my score is 10
Scenario: Correct hard answer scores 50
  Given I register a team
  When I submit a correct hard answer
  Then my score is 50

Die Syntax der Sprache Gherkin (englisch für Essiggurke) wird von einigen Werkzeugen der Cucumber-Familie [7] (englisch für Gurke) implementiert. Was „Gurken“ mit Anforderungen oder Akzeptanztests zu tun haben, ist eine nette (private) Geschichte, des ursprünglichen Entwicklers Aslak Hellesøy – Sie können sie auf Quara selbst einmal nachlesen.

Interessant ist noch, dass die Schlüsselworte der Sprache Gherkin neben dem ursprünglichen Englisch in viele (>50) andere natürliche Sprachen übersetzt worden sind, damit Fachleute überall auf der Welt in ihrer eigenen Sprache Features und Szenarien mit BDD konkretisieren können. Hier im Artikel bleiben wir aber mal bei Englisch.

Scenario Outline: Earning interest
  Given I have an account of type  with a balance of 
  When the monthly interest is calculated
  Then I should have earned at an annual interest rate of  
  And I should have a new balance of 

Vom Szenario zur Ausführung

Zur Ausführung unserer Szenarien setzen wir jetzt Frameworks wie Cucumber, JBehave oder Spock ein. In Abbildung 3 sehen Sie die Zusammenhänge im Überblick. Beginnen wir mit Cucumber (wobei diese Erläuterungen fast identisch auch für JBehave oder das SpecFlow-Framework im .NET-Umfeld gelten). Cucumber kann unser Team-Scoring-Feature von oben schon ausführen, beschwert sich allerdings über „undefined steps“. Logisch, denn bislang fehlt unseren Given-When-Then Szenarien ja noch immer die Verbindung zum Quellcode unseres Systems.

Dazu schreiben wir für Cucumber so genannte Step-Definitions, die unsere textuellen Beschreibungen im .feature-File interpretieren. Das sieht dann wie folgt aus:

@Given("I register a team")
public void i_register_a_team() {
  // Anwendungscode...
}

In der @Given-Annotation wiederholen wir den Text aus der Given-Klausel unseres Szenarios. Diese Source steht in einer normalen Java- oder Groovy-Klasse – in der wir natürlich auch Variablen für unser Team, den Score oder andere schicke Dinge deklarieren können, respektive unseren eigentlichen Quellcode aufrufen. Sie raten jetzt richtig: Es gibt ebenfalls die Annotationen @When und @Then, die analog funktionieren.

JAX – Die Konferenz für Java, Architektur- und Software-Innovation

Agile in einer komplexen Welt: Make it small – slice it!

mit Joana Teschendorff

Workshop: Essential Architectural Thinking – Recalibrating the Compass in a post-agile World

mit Uwe Friedrichsen

Diese Kolumne kann und möchte lediglich einen Überblick über die Möglichkeiten ausführbarer Spezifikationen geben – für eine gründliche Einführung schauen Sie in [1] oder auf auf der cucumber.io-Webseite.

Abb. 3: Features und ausführbare Szenarien nach [1]

Spock und BDD

Einer von uns Autoren (Gernot) ist erklärter Fan von Spock und hat eine Menge Code Test- und/oder Specification-driven mit Hilfe dieses großartigen Werkzeugs entwickelt. In Abbildung 3 finden Sie Spock zusammen mit dem klassischen JUnit als Möglichkeit, Low-Level-Spezifikationen zu schreiben, da Spock mit Fokus auf codenahe Stakeholder entwickelt wurde und nicht wie Gherkin den Fokus auf Businessstakeholder richtet. Spock-Spezifikationen sind bezüglich des Kodieraufwands wesentlich einfacher und schlanker als Gherkin-Features mit ihren (eigenständigen respektive zusätzlichen) Step-Definitionen. Andererseits können wir uns kaum Businessstakeholder vorstellen, die (freiwillig) Spock-Spezifikationen lesen und schreiben würden, denn sie lesen sich ähnlich codelastig wie die Step-Definitionen von Cucumber.

Falls Sie als Entwickler jedoch spezifizieren möchten, dass in einer bestimmten Situation eine Exception eines bestimmten Typs geworfen wird (oder auch nicht), dann ist Spock bestimmt die eleganteste und einfachste Art, das zu tun. Daher nimmt Spock in der von Gherkin dominierten BDD-Welt eine wichtige Rolle ein – und wir empfehlen es besonders für JVM-basierte Systeme wärmstens.

Ausblick

Es geht, wie so oft, noch einen kleinen Schritt weiter. Die ausgeführten Spezifikationen werden durch JUnit-ähnliche Runner ausgeführt – und von denen können wir einen Report generieren lassen: Diesen Ansatz finden wir als Living Documentation etwa in Serenity frei verfügbar umgesetzt. Die Ergebnisse haben uns stark beeindruckt und können bestimmt auch Ihnen in ihrer (schweren!) täglichen Architektur- und Entwicklungsarbeit helfen!

Fazit

Behavior-driven Development ist für unsere Architektenrolle wirklich interessant und gewinnbringend: Brechen Sie (mit Hilfe Ihrer Stakeholder) funktionale Anforderungen auf Fähigkeiten und Features herunter und diese dann auf Szenarien (aka Stories), wobei Sie von den (High-Level-)Geschäftszielen ausgehen. Mit ein wenig zusätzlichem Glue Code (in der JVM-Welt: Cucumber/Gherkin, JBehave oder Spock) bekommen Sie auf diese Weise ausführbare Spezifikationen mit ordentlichen Akzeptanzkriterien. Die Krönung: „Lebendige Dokumentation“, die sich mit jeder Ausführung Ihrer Spezifikationen neu generiert, ist ein garantiert aktueller Überblick darüber, welche Features gerade funktionieren und wo es Probleme gibt.

Wer die letzten Folgen unserer Kolumne gelesen hat, wird direkt an manche noch fehlenden Qualitätsanforderungen denken, aber mit Hilfe der ausführbaren Spezifikationen gemäß BDD können wir schon mal einen ganz ordentlichen Teil von Anforderungen erfassen und kontinuierlich testen. Insofern können Sie loslegen, ein paar Szenarien für Ihr aktuelles System schreiben und von einem der BDD-Tools mal ausführen lassen. In diesem Sinne: Bis zur nächsten Folge, und möge die Macht ausführbarer Specs mit Ihnen sein!