Die Technik des BDD legt den Augenmerk auf den eigentlichen Businesswert, der mit der geschriebenen Software erreicht und durch den Kunden abgenommen werden soll. Die Konzentration liegt auf den Features, die wirklich durch das zu entwickelnde System umgesetzt werden sollen und somit auch auf dem, was der Kunde schlussendlich möchte.
Dabei werden die Features in einer DSL, einer Domain Specfic Language, beschrieben und in enger Zusammenarbeit mit dem eigentlichen Stakeholder erstellt. Die Analyse dient also als spätere Grundlage für die zu testende Funktionailtität und auch als Grundlage der zu erstellenden Akzeptanztests. Ziel ist es eine Ebene zu finden auf der sowohl die Analytiker, als auch die Entwickler miteinander sprechen und Ergebnisse erzielen können. Dabei soll die Sprache der sogenannten Templates so einfach sein, dass sie sowohl von den Analyitkern, als auch von den Entwicklern verstanden wird.
Die Features werden innerhalb eines Feature-File inkl. der zugrunde liegenden Akzeptanzkritierien erfasst und stellen die Grundlage für die darauf aufbauenden Tests dar. Wichtig ist, dass die Feature-Files bereits vor der eigentlichen Entwicklung erstellt werden. Dies dient sowohl der Abstimmung mit dem Kunden, als auch der Reflektion der zu entwickelnden Funktionalität durch die Entwickler selbst. Die Feature-Files sollten bereits vor Start des Entwicklungsprozesses durch die Stakeholder, QS und die Entwickler abgenommen werden.
Am einfachsten lässt sich die Technik an einem einfachen Beispiel demonstrieren. Das Beispiel stellt einen einfachen Taschenrechner dar, der die vier Grundrechenarten beherrscht. Dieser soll durch seine Features beschrieben werden und wird schlussendlich in seiner Implementierung getestet.
Im ersten Schritt werden die fachlichen Anforderungen an den Taschenrechner definiert. Dies ist die eigentliche Aufgabe des Fachbereiches bzw. die des fachlich verantwortlichen Ansprechpartners und stellt die Grundlage für die Akzeptanztests dar. Die Features werden mit Hilfe einer einfachen DSL beschrieben und beinhalten bereits die Testdaten, die dem Test als Grundlage dienen.
Als repräsentatives Beispiel für die Feature-Files wird die Beschreibung der Addition dargestellt:
Das Feature ist in diesem Fall der Taschenrechner (Calculator) mit dem konkreten Szenario der Addition. Die Addition wird beschrieben durch die drei Schritte Given, When und Then. Given beschreibt die Voraussetzungen, When beschreibt die eigentliche Durchführung und schlussendlich beschreibt Then das erwartete Ergebnis. Dazu gibt es noch weitere Schlüsselwörter, die an dieser Stelle allerdings noch keine keine Erwähnung finden.
Im Bereich Examples finden sich die Beispieldaten für die Akzeptanztests. Die Platzhalter, gekennzeichnet durch die spitzen Klammern (<a>,<b> oder <result>) werden durch die Werte aus einer Zeile ersetzt.
Nachdem die Features beschrieben sind, kann die Implementierung und der eigentliche Test durchgeführt werden. Wird streng nach TDD vorgegangen können zuerst die Tests generiert werden und danach wird die eigentliche Implementierung durchgeführt. Für die Implementierung wird ein einfaches Projekt benötigt. Der Einfachheit halber wird das Projekt an dieser Stelle mit der Hilfe von Maven verwaltet. Für die Implementierung des Taschenrechners und das Durchführen der werden nur wenige Dependencies benötigt.
Zusätzlich kann noch ein Plugin für das Reporting eingebunden werden, dies ist aber für das einfache Beispiel nicht notwendig, da alle Ausgaben auf der Konsole beobachtet werden.
Sind die Features syntaktisch korrekt beschrieben worden, kann ein einfacher erster Test durchgeführt werden. Dazu wird eine Basisklasse erstellt, die später mit Hilfe der Cucumber-JVM den Test ausführt.
Aus den generierten Methoden-Stubs kann die vollständige Implementierung des Tests bzw. der Step Definitionen erstellt werden.
Die Tests werden an dieser Stelle durch die leere Implementierung des Taschenrechners immer noch fehlschlagen. Daher wird im zweiten Schritt der Taschenrechner an sich implementiert.
Nachdem der Taschenrechner implementiert ist, sollten die Tests hoffentlich erfolgreich sein.
Somit sind alle Akzeptanztests, die der Fachbereich definiert hat erfolgreich gewesen und der Taschenrechner arbeitet wie gewünscht. Die Grenzfälle, wie in diesem Fall die Division durch 0 wird durch einen einzelnen Unit-Test abgedeckt und ist nicht mehr Teil des Features.
Die Beispiele finden sich wie immer im Repository!
Keine Kommentare:
Kommentar veröffentlichen