Beim ATDD (Acceptance Test Driven Development – Fachtest-getriebene Entwicklung) und BDD (Behaviour Driven Development – Verhaltensgetriebene Entwicklung) ist folgende Syntax weit verbreitet, um vor- und nachgelagerten Bedingungen eines Tests zu formulieren:
- Given: Die statischen Vorbedingungen
- When: Das Verhalten, das zu testen (bzw. zu spezifizieren) ist
- Then: Die Ergebnisse des Verhaltens bei gegebenen Vorbedingungen
In diesem Zusammenhang wird auch gerne von ausführbaren Spezifikationen gesprochen, allerdings ist es bis dahin noch ein weiter Weg, oder?
Das Ziel ist es ein Verhalten so beschreiben zu können, dass es zugleich Spezifikation und Test ist. Dadurch entfällt die in Projekten immer entstehende Divergenz zwischen den Spezifikationen und dem was ein System tatsächlich tut.
Neben der weitgehen natürlichsprachlichen Testbeschreibung wird das genaue Verhalten aber erst durch weitere Beispiele verständlich. Diese unterscheiden sich oft nur in Details, sodass sich hier die tabellarische Form sehr empfiehlt. Die Kombination aus Verhaltensbeschreibung durch die Given/When/Then-Struktur in Verbindung mit weiteren Beispieltabellen erscheint hierbei zur Zeit ideal. Sie enthält alle technischen Details, um den Fachtest automatisieren zu können, ist kompakt genug, um übersichtlich zu bleiben und ist nicht zuletzt auch für den Fachbereich verständlich, sodass sie sehr gut als Diskussionsgrundlage genutzt werden kann. Eventuell kann sie sogar vom gesamten Team zusammen mit dem Fachbereich in einem sogennanten „Specification Workshop“ erstellt werden (siehe auch „Bridging the Communication Gap“, von Gojko Adzic).
Unterstützt wird die Struktur momentan z.B. sowohl von FITNesse als auch Cucumber unterstützt.
Mit der momentan aktuellsten Version des Robot Frameworks (2.1.2) gibt es eine verbesserte Unterstützung für die „umgangssprachliche“ Definition von Testfällen:
- „Given“, „When“, „Then“ und „And“ werden bei User Keywords am Anfang ignoriert
- Parameter können in Keywords eingebettet werden
Dadurch lassen sich nun wunderschön ausführbare Spezifikationen formulieren. Hier ein Beispiel:
1*** Settings *** 2Resource ${RESOURCES}/BDD.txt 3 4*** Keyword *** 5Example 6 [Arguments] ${periodClosed} ${periodOpenAndModified} ${importDay} ${oldManagerValidUntil} ${newManagerValidFrom} 7 8 Given initialized criteria for bonus commercial 9 And a branch B with branch manager M_OLD and employee E1 10 And evaluation for E1 for period ${periodClosed} which is closed 11 And evaluation for E1 for period ${periodOpenAndModified} which is open and modified 12 13 When M_NEW becomes new manager of branch B 14 And import service is called on ${importDay} 15 16 Then the new branch manager of branch B is M_NEW valid from ${newManagerValidFrom} 17 And branch manager M_OLD manages employee E until ${oldManagerValidUntil} 18 And branch manager M_NEW manages employee E from ${newManagerValidFrom} 19 And Evaluations for E1 still have the same content 20 21| *Test Case* | | *Closed Period* | *Open Period* | *Run Import On* | *Old Manager Stops* | *New Manager Starts* | 22| 1 | Example | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 11.11.2009 | 30.11.2009 | 1.12.2009 23| 2 | Example | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.11.2009 | 31.10.2009 | 1.11.2009 24| 3 | Example | 1.11.2009 - 30.11.2009 | 1.12.2009 - 31.12.2009 | 1.12.2009 | 30.11.2009 | 1.12.2009
So hat man eine sehr komprimierte und von vielem, unnötigen Ballast befreite ausführbare Spezifikation. Fast schon unglaublich, dass sich das tatsächlich ausführen lässt:
- Das Beispiel ist eine Robot Test Suite, welche ein User Keyword „Example“ und drei Test Cases „1“, „2“ und „3“ enthält
- Während die Test Cases den „data-driven-style “ verwenden, benutzt das User Keyword den neuen „behaviour-driven-style „
- Durch die Verwendung des reinen Textmodus braucht man keinen externen Editor. Im Gegenteil, die RIDE (Robot IDE) hat die unangenehme Angewohnheit die User Keywords unter den Test Cases zu speichern, was normalerweise auch sinnvoll, in diesem Fall aber dem Leseverständnis abträglich ist.
- Einige Parameter in den User Keywords werden parametrisiert, wie z.B. ${importDay}, andere werden für diesen Testfall vorgegeben, wie z.B. der Name der Niederlassung B. Es ist essentiell die Beispieltabelle auf die relevanten Daten zu beschränken, damit diese übersichtlich bleibt.
- Das User Keyword „Examples“ wird in jeder Test Suite neu definiert. Da Robot aber bei multiplen Definitionen immer derjenigen aus der aktuellen Suite den Vorrang einräumt stellt dies kein Problem dar, ganz im Gegenteil, so kann das Format der Beispieltabelle über alle Test Suites konsistent gehalten werden.
- Die Beispieltabelle nutzt das Pipesymbol „|“ zur Abtrennung der Spalten. Dies ermöglicht die Spalten zu benennen, die Titel haben keine Auswirkung auf die Parameterübergabe, allein die Reihenfolge der Parameter muss mit der Zeile „[Arguments]“ übereinstimmen.
- Die konkreten Testfälle in der Beispieltabelle sind einfach durchnummeriert; dies erhöht die Kompaktheit der Tabelle.
- Das Setup und Teardown des Tests muss ein wenig versteckt im ersten User Keyword stattfinden (hier „initialized criteria for bonus commercial“). Andrerseits interessiert das fachlich ja auch nicht, wie ein System in einen definierten Ursprungszustand versetzt wird.
- Die ausführbaren Spezifikationen können durch eine Verzeichnisstruktur gruppiert und User Stories zugeordnet werden.
Wie werden die fast natürlichen Sätze nun automatisiert? Dies sei am Beispiel der ersten Nachbedingung verdeutlicht. Die Resource-Datei BDD.txt enthält alle User Keywords, welche diese ausführbare Spezifikation ausführbar machen:
1*** Settings *** 2Library de.codecentric.fourtexx.robot.ModelKeyword 3 4*** Keywords *** 5the new branch manager of branch ${branch} is ${manager} valid from ${newManagerValidFrom} 6 Assert Branch Manager Valid From ${branch} ${manager} ${newManagerValidFrom}
Man beachte, dass nicht nur das Datum parametrisiert ist, sondern auch der Name der Niederlassung und des Leiters der Niederlassung. Im konkreten Beispiele würden hier die Parameter B, M_NEW und (je nach Test Case) 1.12.2009 oder 1.11.2009 übergeben. Das hier definierte User Keyword ist nicht viel mehr als die Weiterleitung auf ein in Java implementiertes User Keyword. Dort kann dann nach belieben getan werden, was getan werden muss, um sicherzustellen, dass die geforderte Fachlichkeit erfüllt ist.
1public void assertBranchManagerValidFrom(String branch, String manager, String validFrom) throws Exception {
2 // ...
3}
Fazit: Mit den neuen Möglichkeiten von Robot 2.1.2 zieht es meiner Meinung nach mindestens mit den anderen Kandidaten im Rennen gleich. Die gefundene Möglichkeit ausführbare Spezifikationen inklusive anghängter Beispieltabelle in Textform zu formulieren scheint ideal, um Spezifikationen, Beispiele und Test wirklich auf ein Artefakt zusammenzuführen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
18.11.2020 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.