© maljuk/Shutterstock.com
Java Magazin
Akzeptanztests in Java mit JGiven

Lessons learned

Die meisten Entwickler wissen, was Komponententests sind, auch wenn sie selbst keine schreiben. Aber es gibt noch Hoffnung: Die Situation ändert sich, und immer mehr auf GitHub gehostete Projekte enthalten Unit-Tests. In einer Standardkonfiguration für Java-Projekte mit NetBeans, Maven und JUnit ist es nicht ganz so schwer, die ersten Zeilen Testcode zu erstellen. Neben dem Ansatz, der in Test-driven Development (TDD) verwendet wird, gibt es noch andere Technologien wie Behavior-driven Development (BDD), auch Akzeptanztests genannt, die wir in diesem Artikel vorstellen möchten.

Marco Schulz


Der leichteste Weg, um in das Thema einzusteigen, ist ein einfacher Vergleich zwischen Unit- und Akzeptanztests. In diesem Zusammenhang sind Unit-Tests auf sehr niedrigem Niveau angesiedelt. Es wird eine Funktion ausgeführt und die Ausgabe mit einem zu erwarteten Ergebnis verglichen. Allerdings teilen nicht alle die Meinung, dass der Entwickler als einziger für die Unit-Tests verantwortlich ist. Schließlich liegt der Testcode auch im Projektverzeichnis und wird mit jedem Build ausgeführt. Das wiederrum führt dazu, dass man sehr früh Rückmeldung erhält, ob etwas schiefgelaufen ist. Solange der Test nicht zu viele Aspekte abdeckt, kann das Problem recht schnell identifiziert und behoben werden. Das Designprinzip solcher Tests folgt dem AAA-Paradigma.

Zuerst wird eine Vorbedingung definiert (Arrange), dann die Invariante exekutiert (Act), um anschließend die Nachbedingungen (Assume) zu überprüfen. Auf diesen Ansatz werden wir später noch einmal zurückkommen. Wenn wir die Testabdeckung mit Werkzeugen wie JaCoCo überprüfen und unser Code zu mehr als 85 Prozent mit Testfällen abgedeckt ist, können wir von einer guten Qualität ausgehen. Während der Erhöhung der Testabdeckung werden die Testfälle immer konkreter spezifiziert und dadurch auch genauer und das versetzt uns in die Lage, eigene Optimierungsmöglichkeiten zu identifizieren. Das kann das Entfernen oder Invertieren von Bedingungen sein, da während der Tests festgestellt wird, dass es beinah unmöglich ist, diese Abschnitte zu erreichen. Natürlich ist das Thema etwas komplizierter und umfangreicher, weswegen diese Details in einem anderen Artikel besprochen werden sollten.

Abnahmetests sind genauso zu klassifizieren wie Komponententests – sie gehören zur Familie der Regressionstests. Das heißt, im Grunde möchten wir sicherstellen, dass Änderungen, die wir am Code vorgenommen haben, keine Auswirkungen auf die bereits fertiggestellte Funktionalität haben. Das Werkzeug unserer Wahl hierfür ist JGiven [1]. Bevor wir nun mit einigen Beispielen fortfahren, müssen wir aber noch ein bisschen Theorie besprechen.

JGiven im Detail

Die Testfälle, die wir in JGiven definieren, heißen Szenarien. Ein Szenario ist eine Sammlung von vier Klassen, nämlich: das Szenario selbst, das als given angezeigte Arrange, die als when angezeigte Action (Act) und das als then angezeigte Outcome (Assume). In den meisten Projekten, insbesondere wenn eine Vielzahl von Szenarien vorliegt und die Ausführung viel Zeit in Anspruch nimmt, werden A...

Java Magazin
Akzeptanztests in Java mit JGiven

Lessons learned

Die meisten Entwickler wissen, was Komponententests sind, auch wenn sie selbst keine schreiben. Aber es gibt noch Hoffnung: Die Situation ändert sich, und immer mehr auf GitHub gehostete Projekte enthalten Unit-Tests. In einer Standardkonfiguration für Java-Projekte mit NetBeans, Maven und JUnit ist es nicht ganz so schwer, die ersten Zeilen Testcode zu erstellen. Neben dem Ansatz, der in Test-driven Development (TDD) verwendet wird, gibt es noch andere Technologien wie Behavior-driven Development (BDD), auch Akzeptanztests genannt, die wir in diesem Artikel vorstellen möchten.

Marco Schulz


Der leichteste Weg, um in das Thema einzusteigen, ist ein einfacher Vergleich zwischen Unit- und Akzeptanztests. In diesem Zusammenhang sind Unit-Tests auf sehr niedrigem Niveau angesiedelt. Es wird eine Funktion ausgeführt und die Ausgabe mit einem zu erwarteten Ergebnis verglichen. Allerdings teilen nicht alle die Meinung, dass der Entwickler als einziger für die Unit-Tests verantwortlich ist. Schließlich liegt der Testcode auch im Projektverzeichnis und wird mit jedem Build ausgeführt. Das wiederrum führt dazu, dass man sehr früh Rückmeldung erhält, ob etwas schiefgelaufen ist. Solange der Test nicht zu viele Aspekte abdeckt, kann das Problem recht schnell identifiziert und behoben werden. Das Designprinzip solcher Tests folgt dem AAA-Paradigma.

Zuerst wird eine Vorbedingung definiert (Arrange), dann die Invariante exekutiert (Act), um anschließend die Nachbedingungen (Assume) zu überprüfen. Auf diesen Ansatz werden wir später noch einmal zurückkommen. Wenn wir die Testabdeckung mit Werkzeugen wie JaCoCo überprüfen und unser Code zu mehr als 85 Prozent mit Testfällen abgedeckt ist, können wir von einer guten Qualität ausgehen. Während der Erhöhung der Testabdeckung werden die Testfälle immer konkreter spezifiziert und dadurch auch genauer und das versetzt uns in die Lage, eigene Optimierungsmöglichkeiten zu identifizieren. Das kann das Entfernen oder Invertieren von Bedingungen sein, da während der Tests festgestellt wird, dass es beinah unmöglich ist, diese Abschnitte zu erreichen. Natürlich ist das Thema etwas komplizierter und umfangreicher, weswegen diese Details in einem anderen Artikel besprochen werden sollten.

Abnahmetests sind genauso zu klassifizieren wie Komponententests – sie gehören zur Familie der Regressionstests. Das heißt, im Grunde möchten wir sicherstellen, dass Änderungen, die wir am Code vorgenommen haben, keine Auswirkungen auf die bereits fertiggestellte Funktionalität haben. Das Werkzeug unserer Wahl hierfür ist JGiven [1]. Bevor wir nun mit einigen Beispielen fortfahren, müssen wir aber noch ein bisschen Theorie besprechen.

JGiven im Detail

Die Testfälle, die wir in JGiven definieren, heißen Szenarien. Ein Szenario ist eine Sammlung von vier Klassen, nämlich: das Szenario selbst, das als given angezeigte Arrange, die als when angezeigte Action (Act) und das als then angezeigte Outcome (Assume). In den meisten Projekten, insbesondere wenn eine Vielzahl von Szenarien vorliegt und die Ausführung viel Zeit in Anspruch nimmt, werden A...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang