© Excellent backgrounds/Shutterstock.com
Java Magazin
Behavior-driven Integration Testing mit Cucumber und Citrus

Testen mit Gurken und Zitronen

Das Konzept von Behavior-driven Development (BDD) stellt die gute und verständliche Beschreibung des Verhaltens einer Anwendung in den Vordergrund. Fachexperten erstellen gemeinsam mit der Entwicklung die Spezifikationen in Form von Gherkin-Feature-Szenarien. Anschließend können BDD-Tools wie Cucumber diese Feature-Stories direkt interpretieren und als Tests ausführbar machen. Man erhält also eine Kombination aus gut lesbaren Verhaltensregeln, Tests und Dokumentation bei gleichzeitiger Verbesserung der Kommunikation zwischen Fachabteilung und Entwicklung. Lassen sich diese Konzepte auf die Integrationstests einer Anwendung mit nachrichtenbasierten Schnittstellen übertragen?

Christoph Deppisch


Die gute Zusammenarbeit zwischen Fachabteilung und Softwareentwicklung scheitert in vielen Fällen bereits an umständlichen Kommunikationswegen und dem generell unterschiedlichen Sprachjargon der Beteiligten. Die spezifizierten Features aus der Fachabteilung sind unvollständig, mehrdeutig oder werden einfach nicht richtig verstanden. Missverständnisse und fehlendes Verständnis für die Begriffe des Anderen sind Ursachen für aufwendige Änderungszyklen. Es müssen immer wieder Anpassungen vorgenommen werden, bis am Ende endlich das gewünschte Ergebnis feststeht. Behavior-driven Development bietet genau hier einen Ansatz für eine bessere Kommunikation zwischen Fachabteilung und Entwicklung und verspricht ein einfaches Verständnis für alle Beteiligten. Die Given-When-Then-Syntax von Gherkin ist Grundlage dieses Versprechens. Die Features werden in mehreren Szenarien mit Given-When-Then-Schritten beschrieben. Die daraus entstandene Spezifikation ist sowohl von der Fachabteilung als auch von den technischen Experten gut lesbar und bildet eine gemeinsame Sprachgrundlage.

Für die Demonstration der BDD-Konzepte benötigen wir eine einfache Beispielanwendung. Die Voting-App-Anwendung erstellt und verwaltet Umfragen und bietet dem Benutzer die Möglichkeit zur Abstimmung. Natürlich soll die Anwendung auch die Umfrageergebnisse darstellen können. Die Voting-App ist eine Spring-Boot-Webanwendung und kann vom Browser aus bedient werden. Abbildung 1 und Abbildung 2 zeigen Auszüge der Benutzeroberfläche im Browser. Der gesamte Beispielcode der Anwendung sowie alle Cucumber- und Citrus-Tests in diesem Artikel können von GitHub [1] heruntergeladen und mit Maven ausgeführt werden.

Abb. 1: Übersicht der Umfragen

Abb. 2: Stimmabgabe und Ergebnisse

Die Beispielanwendung selbst ist einfach gehalten. Der Benutzer legt neue Umfragen an, gibt eventuell spezielle Antwortmöglichkeiten vor, kann seine Stimme abgeben und die Umfrageergebnisse anzeigen lassen.

BDD-Featurespezifikation beschreiben

Wir wollen nun unser erstes Feature für die Voting-App beschreiben und in einem Behavior-driven Unit-Test prüfen. Listing 1 zeigt die Gherkin-Featurespezifikation für das Anlegen von neuen Umfragen mit diversen Antwortmöglichkeiten, Listing 2 die Szenarien für die Abstimmung und die Ergebnisberechnung. Die Struktur mit Gherkin hilft dabei, das geforderte Verhalten genau und verständlich zu beschreiben. Die Szenarien beschreiben das Verhalten dabei immer mit einem konkreten praktischen Beispiel. Das Fe...

Java Magazin
Behavior-driven Integration Testing mit Cucumber und Citrus

Testen mit Gurken und Zitronen

Das Konzept von Behavior-driven Development (BDD) stellt die gute und verständliche Beschreibung des Verhaltens einer Anwendung in den Vordergrund. Fachexperten erstellen gemeinsam mit der Entwicklung die Spezifikationen in Form von Gherkin-Feature-Szenarien. Anschließend können BDD-Tools wie Cucumber diese Feature-Stories direkt interpretieren und als Tests ausführbar machen. Man erhält also eine Kombination aus gut lesbaren Verhaltensregeln, Tests und Dokumentation bei gleichzeitiger Verbesserung der Kommunikation zwischen Fachabteilung und Entwicklung. Lassen sich diese Konzepte auf die Integrationstests einer Anwendung mit nachrichtenbasierten Schnittstellen übertragen?

Christoph Deppisch


Die gute Zusammenarbeit zwischen Fachabteilung und Softwareentwicklung scheitert in vielen Fällen bereits an umständlichen Kommunikationswegen und dem generell unterschiedlichen Sprachjargon der Beteiligten. Die spezifizierten Features aus der Fachabteilung sind unvollständig, mehrdeutig oder werden einfach nicht richtig verstanden. Missverständnisse und fehlendes Verständnis für die Begriffe des Anderen sind Ursachen für aufwendige Änderungszyklen. Es müssen immer wieder Anpassungen vorgenommen werden, bis am Ende endlich das gewünschte Ergebnis feststeht. Behavior-driven Development bietet genau hier einen Ansatz für eine bessere Kommunikation zwischen Fachabteilung und Entwicklung und verspricht ein einfaches Verständnis für alle Beteiligten. Die Given-When-Then-Syntax von Gherkin ist Grundlage dieses Versprechens. Die Features werden in mehreren Szenarien mit Given-When-Then-Schritten beschrieben. Die daraus entstandene Spezifikation ist sowohl von der Fachabteilung als auch von den technischen Experten gut lesbar und bildet eine gemeinsame Sprachgrundlage.

Für die Demonstration der BDD-Konzepte benötigen wir eine einfache Beispielanwendung. Die Voting-App-Anwendung erstellt und verwaltet Umfragen und bietet dem Benutzer die Möglichkeit zur Abstimmung. Natürlich soll die Anwendung auch die Umfrageergebnisse darstellen können. Die Voting-App ist eine Spring-Boot-Webanwendung und kann vom Browser aus bedient werden. Abbildung 1 und Abbildung 2 zeigen Auszüge der Benutzeroberfläche im Browser. Der gesamte Beispielcode der Anwendung sowie alle Cucumber- und Citrus-Tests in diesem Artikel können von GitHub [1] heruntergeladen und mit Maven ausgeführt werden.

Abb. 1: Übersicht der Umfragen

Abb. 2: Stimmabgabe und Ergebnisse

Die Beispielanwendung selbst ist einfach gehalten. Der Benutzer legt neue Umfragen an, gibt eventuell spezielle Antwortmöglichkeiten vor, kann seine Stimme abgeben und die Umfrageergebnisse anzeigen lassen.

BDD-Featurespezifikation beschreiben

Wir wollen nun unser erstes Feature für die Voting-App beschreiben und in einem Behavior-driven Unit-Test prüfen. Listing 1 zeigt die Gherkin-Featurespezifikation für das Anlegen von neuen Umfragen mit diversen Antwortmöglichkeiten, Listing 2 die Szenarien für die Abstimmung und die Ergebnisberechnung. Die Struktur mit Gherkin hilft dabei, das geforderte Verhalten genau und verständlich zu beschreiben. Die Szenarien beschreiben das Verhalten dabei immer mit einem konkreten praktischen Beispiel. Das Fe...

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