© Excellent backgrounds/Shutterstock.com
Teil 1: Einführung in Behavior-driven Development mit JBehave

Verhaltensregeln für Anwendungen


JBehave ist das erste Framework, das Behavior-driven Development (BDD) umsetzt. Es existiert schon seit geraumer Zeit, ist Open Source und freundet sich mit agilen Projekten schnell an. Trotzdem ist es kaum bekannt und eher ein Geheimtipp. Im ersten Teil der Artikelserie möchte ich BDD vorstellen und aufzeigen, wie JBehave eingesetzt werden kann, um damit Tests besser zu automatisieren.

Artikelserie

Teil 1: Einführung in Behavior-driven Development mit JBehave

Teil 2: Fortgeschrittene Testautomatisierung mit JBehave und Selenium

Behavior-driven Development (BDD) wurde von Dan North ins Leben gerufen und ist eine Weiterentwicklung des Test-driven Developments. Die Verbesserung besteht hauptsächlich darin, dass beim BDD ein klarer Rahmen existiert, an dem sich die Erstellung von Testfällen und die Dokumentation der Tests orientiert. Man beschreibt das Verhalten der Anwendung in Form von ausführbaren Akzeptanzkriterien, welche zugleich die Testfälle repräsentieren. Damit dokumentiert sich der automatisierte Test weitgehend selbst, auch für Nichtprogrammierer. Man schlägt also zwei Fliegen mit einer Klappe.

Dan North machte die unangenehme Erfahrung, dass es beim Test-driven Development häufig zu Verwirrung und Missverständnissen kommt. Immer wieder fragte man sich als Programmierer, worauf sich Tests beziehen müssen, was getestet werden soll und was nicht, wie viele Aktionen und Verifikationen ein einzelner Test beinhalten darf, wie die Testfälle benannt werden sollten und wie man verstehen kann, warum ein Test gescheitert ist. Ein Problem mit JUnit oder ähnlichen Testframeworks ist, dass in der Praxis oft undurchsichtig ist, was ein Test eigentlich macht. Die Namen der Testmethoden tragen meist wenig zum Verständnis bei. Über die Jahre haben sich Praktiken ergeben, um diese Schmerzen zu lindern. Zu diesen Maßnahmen gehört, die Testfälle mit sprechenden und längeren Namen zu versehen, das Pattern Given/When/Then anzuwenden und sie bei Bedarf zu parametrisieren. In der Praxis werden solche guten Praktiken aber selten genutzt. Und selbst wenn – das Grundproblem bleibt: die Ausrichtung des Denkens und des Frameworks rund um die Vorstellung „Test“ herum.

Oh, Behave!

Immer deutlicher erkannte Dan North, dass der Ausdruck „Test“ bei der Automatisierung zu babylonischer Sprachverwirrung führt, und ersetzte ihn durch den Begriff Verhalten. Die Idee dahinter ist, dass die Testfälle das Verhalten der Anwendung beschreiben sollen. Damit ist enträtselt, woran sich die...

Neugierig geworden?

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