Verbesserte JBehave Steps mit Varianten

In einem früheren Post wurde bereits eine kleine Einführung in das JBehave Projekt zur Automatisierung von Akzeptanztests gegeben. Während sich dieser Artikel mit der Installation und der allgemeinen Verwendung des Frameworks beschäftigte, konzentriere ich mich heute auf eine Erweiterung, die ich kürzlich zum Projekt beigesteuert habe, und die es erlaubt, Test Stories in noch natürlicherer Sprache abzufassen, als bislang möglich.

Bisher bei LOST JBehave

Ein kurzer Rückblick: In JBehave werden Tests in Sätzen in natürlicher Sprache verfasst, die zur Ausführungszeit auf korrespondierende Methoden abgebildet werden. Folgendes Beispiel stammt aus der JBehave Dokumentation (übersetzt):

1@When("der Artikelpreis $preis ist")
2@Aliases(values={"der Artikelpreis $preis beträgt"
3             "der Artikelpreis $preis entspricht"}) // mehrere Aliase
4public void derPreisIst(double preis) {
5    // ...
6}

Diese Methode wird aufgerufen, wenn in einer Test-Story eine der folgenden Zeilen steht:

• Wenn der Artikelpreis 10 ist
• Wenn der Artikelpreis 10 beträgt
• Wenn der Artikelpreis 10 entspricht

Die Bereitstellung dieser verschiedenen Formulierungen, die jeweils das identische technische Verhalten auslösen, ist für Tester aus verschiedenen Gründen von großem Vorteil. Zunächst muss sich der Autor der Tests nicht exakt an die genaue Schreibweise eines Testschritts erinnern, um die gewünschte Operation auszulösen. Diesem Problem ließe sich mit besserer Editorunterstützung begegnen, z. B. mit dem JBehave Eclipse Plugin .

Darüber hinaus – und meiner Meinung nach ist dies der wichtigere Aspekt – erlaubt es, Test-Stories zu verfassen, die sowohl einfacher zu lesen, aber auch zu schreiben sind. Eine strikte Beschränkung auf genau eine gültige Formulierung pro Testschritt reißt Testautoren tendenziell aus dem Schreibfluss.

Im oben genannten Beispiel ist die Ähnlichkeit zwischen den drei Alternativen sehr deutlich. Sie beginnen alle mit der gleichen Einleitung, gefolgt von einer Variablen $preis, sowie einem jeweils unterschiedlichen Wort am Ende.

Diese Wiederholung von Text führt zu erheblicher Unordnung im Java Source und ist eine hervorragende Quelle für später schwer zu findende Copy und Paste Fehler.

Neu: jetzt mit noch mehr Varianten

Um dem Wiederholungsproblem zu begegnen, schlug ich den JBehave Autoren eine erste Idee vor und stellte einen Patch bereit, um deren Umsetzbarkeit zu demonstrieren. Nach einer kurzen Diskussion – in deren Verlauf mir die Unzulänglichkeiten meines ersten Ansatzes klar wurden – entstand die Idee einer allgemeineren Muster-Syntax. Die Implementierung derselben habe ich als Patch zur Verfügung gestellt, und sie wird Teil des 3.6er Releases sein. Sie erlaubt das oben genannte Beispiel wie folgt zu vereinfachen:

1@When("der Artikelpreis $preis {ist|beträgt|entspricht}")
2public void derPreisIst(double preis) {
3    // ...
4}

Der Wert der @When Annotation enthält nun ein paar geschweifter Klammern, das mehrere an dieser Stelle zulässige Worte einschließt. Intern erzeugt JBehave alle Permutationen, die sich durch diese Option ergeben und behandelt sie gleichwertig, so als wären sie explizit ausformuliert. Natürlich ist diese Syntax auch in “normalen” @Alias Deklarationen möglich.

Es ist durchaus möglich, mehr als einen dieser Blöcke mit Optionen in einer Schritt-Definition mit @Given, @When oder @Then zu verwenden. Hier ein etwas komplexeres Beispiel:

1@Then("{Muss|Sollte|Soll} A $x sein, {außer|es sei denn} es ist {Teil von|enthalten in} {der |}Liste $y")

Wenn man das kurz durchrechnet, ergeben sich daraus insgesamt 24 Permutationen (oder eben “Varianten”, wie sie im JBehave Sprachgebrauch Einzug gehalten haben):

• Drei mögliche Werte für das erste Klammernpaar (“Muss”, “Sollte”, “Soll”)
• Zwei mögliche Werte für das zweite Klammernpaar (“außer”, “es sei denn”)
• Zwei mögliche Werte für das dritte Klammernpaar (“Teil von”, “enthalten in”)
• Zwei mögliche Werte für das vierte Klammernpaar (“der” und ein Leerstring, womit das Wort “der” an dieser Stelle effektiv optional wird)

Diese Varianten alle einzeln in den Source zu schreiben wäre sowohl initial als auch aus Wartungssicht nicht praktikabel. Die neue, sehr prägnante Schreibweise erlaubt es hingegen, dem Entwickler das Leben deutlich zu erleichtern, und gleichzeitig den Testautoren ein großes Maß an Flexibilität einzuräumen.

Das Eclipse Plugin

Gemeinsam mit Arnauld, dem Autoren des JBehave Eclipse Plugin (Sourcecode hier ), habe ich außerdem dafür gesorgt , dass im Plugin eine Snapshot Version von JBehave aufgenommen wurde, die die Varianten-Syntax unterstützt. Damit lässt sich ausprobieren, wie sich das Schreiben von Tests unter Ausnutzung des neuen Features anfühlt. Allerdings ist zu beachten, dass zur Ausführung der Testfälle derzeit noch kein JBehave Release zur Verfügung steht. Hierfür muss man sich die JBehave Quellen von GitHub clonen und selbst einen Snapshot bauen.

Sollten Sie das in der Vergangenheit (insbesondere unter Windows) schon einmal versucht haben, und dabei gescheitert sein, dürfte interessant sein zu wissen, dass das zugrundeliegende Problem dabei inzwischen behoben sein sollte.

Einsatzbereit

In den vergangenen Wochen habe ich das neue Feature in einem Kundenprojekt produktiv eingesetzt und keine Probleme festgestellt – von daher gehe ich davon aus, dass es sich um eine produktiv einsetzbare Funktion handelt. Da sich Snapshot Versionen naturgemäß häufig und ggf. deutlich unterscheiden, lässt sich daraus allerdings keine allgemeingültige Freigabe ableiten. Hier ist also Vorsicht geboten, und je nach persönlicher Einstellung oder Unternehmensvorgabe könnte es angebracht sein, für den tatsächlichen Einsatz auf das finale JBehave 3.6 Release zu warten.

Nichtsdestotrotz hoffe ich, dass dieses neue Feature Anklang finden wird. Über jede Art von Feedback würde ich mich freuen.

Update: Nur ein paar Tage nach der Veröffentlichung dieses Beitrags wurde das 3.6 Release freigegeben. Jetzt steht dem Einsatz dieses neuen Features also nichts mehr im Wege. 🙂