Seite 3: Kombinationsmöglichkeiten

Inhaltsverzeichnis

Kurzer Zwischenstand

Die Testfälle in Gherkin-Syntax zu Beginn des Artikels sind nun lesbarem Java-Code gewichen. Durch zusätzliche runde und geschweifte Klammern sieht der Testfall nun etwas technischer aus, das bewährte Given/When/Then-Schema bleibt aber erhalten.

Der Vorteil von Gwen liegt zunächst bei den Entwicklern, da sie ihre gewohnte Java-Umgebung nicht verlassen müssen und eine gute Hilfestellung beim Schreiben von Testfällen bekommen. Werden die Testfälle mit der Anforderung spezifiziert, können die Entwickler sie in Java-Code mit den bewährten Werkzeugen zur Testautomatisierung implementieren. Die Unterstützung der IDE bietet beim Einsatz von Gwen nur die Methoden an, die zum Schritt (Given, When oder Then) und zum getestenen System passen. Effizientes Refactoring, um zum Beispiel Methoden umzubenennen, wird erst durch Java-Code möglich. Durch die Möglichkeit des Refactoring und die gute automatische Vervollständigung kann sich im Laufe der Zeit aus den Methodennamen Schritt für Schritt eine konsistente fachliche Sprache entwickeln.

Da im Gegensatz zu Cucumber mit Arranger, Actor und Asserter weitere strukturierende Elemente zum Einsatz kommen, sind mehr Klassen zu schreiben. Das relativiert sich allerdings in einer modernen IDE mit intelligenten Templates.

Mit Gwen ist es unwahrscheinlicher als bei Cucumber, dass die Fachseite den Code der Tests schreibt. Während bei dessen Verwendung ein nicht implementierter Schritt im Testergebnis als "undefined" gemeldet wird, sind die Methoden bei Gwen zumindest mit einem fail() umzusetzen.

Trotzdem kann die Fachseite wie gewohnt im Given/When/Then-Schema Testfälle zusammen mit den Anforderungen definieren und darauf vertrauen, diese Struktur bei den implementierten Testfällen wiederzufinden. Bei der Verfeinerung der Testfälle bietet sich ein gemeinsames Implementieren im Sinne des Pair Programming an.

Blick über den Tellerrand

Im zuvor bemühten Beispiel mit dem Taschenrechner lassen sich mehrere Aktionen hintereinander in einer Zeile via Method Chaining aufrufen, da die einzelnen Methoden die aktuelle Instanz zurückliefern.

Wenn in einer Anwendung zwischen Dialogen gewechselt wird, ist es sinnvoller, eine Referenz eines weiteren Teils des zu testenden Systems zurückzugeben. Im Verlauf kann die Testmethode diese mit Given/When/Then benutzen.

Kombiniert man Gwen mit Arquillian Graphene, einem Werkzeug zum Testen von Webseiten, sehen die Testfälle wie unten dargestellt aus. Das bewährte Konzept des Page Object Pattern lässt sich hier mit BDD kombinieren.

@RunWith(Arquillian.class)
public class StartPageFeature {

    @Drone
    protected WebDriver browser;

    @Page
    private StartPage startPage;

    @Test
    public void szenarioSearchWithMatches() {
        given(startPage).isOpenedInBrowser();
        ResultPage resultPage =
                when(startPage).searchesFor("bdd");
        then(resultPage).showsAResultCountOf(3);
    }

}

Die Möglichkeit, Gwen mit anderen Testframeworks zu kombinieren, besteht nur deshalb, weil es keinen eigenen Test-Runner mitbringt. Shazam setzt es beispielsweise mit Robotium (zukünftig Espresso) für Android-Testfälle ein (vgl. Beispiele von Shazam).

Damit unterscheidet sich Gwen grundsätzlich von allen anderen BDD-Testframeworks, die alle einen Runner enthalten.

In größeren Projekten werden die Arranger-, Actor- und Asserter-Klassen, die im weiter oben gezeigten längeren Beispiel innere Klassen sind, als eigenständige Klassen im gleichen Package abgelegt. Sind sie immer noch zu groß, lässt sich jeder Schritt in einer eigenen Klasse als Command implementieren. Gwen stellt hierfür die drei Interfaces Action, Arrangement und Assertion bereit. Ein ausführliches Beispiel dazu findet sich ebenfalls bei Shazam.

Insgesamt besteht das Gwen aus nur einer Klasse mit statischen Methoden und neun Interfaces, die alle in diesem Artikel vorgestellt wurden.