© Excellent backgrounds/Shutterstock.com
Java Magazin
Next-Generation-Enterprise-Tests mit Spock

Test long and prosper!


In diesem Artikel machen wir uns auf in die unendlichen Weiten der testgetriebenen Entwicklung. Lange war es ruhig in den Reihen der Enterprise-Testframeworks. Die Besatzung bestehend aus JUnit, Hamcrest und Mockito hat sich als De-facto-Standard für Unit- und Integrationstests etabliert. Doch mit dem Spock Framework kommt nun ein neues Teammitglied an Bord, das alle Testdisziplinen gleichermaßen gut beherrscht.

Bei Spock handelt es sich um ein Testframework, das bereits seit 2008 entwickelt wird [1]. Es ist somit kein komplett neues Framework mehr. Spock kombiniert die Stärken und guten Ansätze vieler altbekannter Frameworks, wie JUnit, JBehave, Mockito oder Hamrest, in einem einzigen Framework. So bringt das Framework bereits etliche eingebaute Funktionen mit, für die man bisher separate Bibliotheken benötigt hat.

Im Kern setzt Spock auf JUnit auf. Das ist eine gute Wahl, denn Spock integriert sich damit reibungslos in die gängige Entwickler-Tool-Chain im JVM-Umfeld. Es stehen Erweiterungen für IDEs wie IntelliJ oder Eclipse bereit. Die Ausführung der Tests übernehmen wie gewohnt die Plug-ins des bevorzugten Build-Tools, und auch CI-Server kommen mit Spock gut zurecht.

Die Syntax von Spock ist reduziert und ausdrucksstark. Das liegt vor allem an der Verwendung von Groovy, das durch seine Sprachfeatures dazu beiträgt, sich auf das Wesentliche im Test konzentrieren zu können. Entwickler, die bisher noch keine Berührungspunkte mit Groovy hatten, können aber beruhigt sein. Der Wechsel von Java nach Groovy ist in nur wenigen Stunden erfolgt. Danach ist man mindestens genauso produktiv wie mit einem Java-basierten Testframework.

Die Spock Groovy DSL gibt die möglichen Strukturen der Tests klar vor, sie folgt dabei im Wesentlichen einer given-when-then-Notation, wie man sie aus dem Behaviour-driven Development (BDD) kennt. Spock stellt den korrekten Testaufbau sicher und prüft die korrekte Reihenfolge der einzelnen Phasen. So ist es mit Spock nicht möglich, einen Test zu schreiben, der keine einzige Assertion enthält. In Abbildung 1 sind die unterstützten Phasen und Blocks dargestellt.

reimer_spock_1.tif_fmt1.jpgAbb. 1: Blocks und Phasen eines Spock-Tests

Die erste Außenmission mit Spock

Um Spock in einem Projekt zu verwenden, müssen lediglich einige wenige Dependencies über das bevorzugte Build-Tool hinzugefügt werden (Listing 1). Die Spock Core Dependency wird zwingend benötigt, die anderen Dependencies sind optional.

Listing 1: Dependencies hinzufügen

// choose Spock with desired ...
Java Magazin
Next-Generation-Enterprise-Tests mit Spock

Test long and prosper!

In diesem Artikel machen wir uns auf in die unendlichen Weiten der testgetriebenen Entwicklung. Lange war es ruhig in den Reihen der Enterprise-Testframeworks. Die Besatzung bestehend aus JUnit, Hamcrest und Mockito hat sich als De-facto-Standard für Unit- und Integrationstests etabliert. Doch mit dem Spock Framework kommt nun ein neues Teammitglied an Bord, das alle Testdisziplinen gleichermaßen gut beherrscht.

Mario-Leander Reimer


In diesem Artikel machen wir uns auf in die unendlichen Weiten der testgetriebenen Entwicklung. Lange war es ruhig in den Reihen der Enterprise-Testframeworks. Die Besatzung bestehend aus JUnit, Hamcrest und Mockito hat sich als De-facto-Standard für Unit- und Integrationstests etabliert. Doch mit dem Spock Framework kommt nun ein neues Teammitglied an Bord, das alle Testdisziplinen gleichermaßen gut beherrscht.

Bei Spock handelt es sich um ein Testframework, das bereits seit 2008 entwickelt wird [1]. Es ist somit kein komplett neues Framework mehr. Spock kombiniert die Stärken und guten Ansätze vieler altbekannter Frameworks, wie JUnit, JBehave, Mockito oder Hamrest, in einem einzigen Framework. So bringt das Framework bereits etliche eingebaute Funktionen mit, für die man bisher separate Bibliotheken benötigt hat.

Im Kern setzt Spock auf JUnit auf. Das ist eine gute Wahl, denn Spock integriert sich damit reibungslos in die gängige Entwickler-Tool-Chain im JVM-Umfeld. Es stehen Erweiterungen für IDEs wie IntelliJ oder Eclipse bereit. Die Ausführung der Tests übernehmen wie gewohnt die Plug-ins des bevorzugten Build-Tools, und auch CI-Server kommen mit Spock gut zurecht.

Die Syntax von Spock ist reduziert und ausdrucksstark. Das liegt vor allem an der Verwendung von Groovy, das durch seine Sprachfeatures dazu beiträgt, sich auf das Wesentliche im Test konzentrieren zu können. Entwickler, die bisher noch keine Berührungspunkte mit Groovy hatten, können aber beruhigt sein. Der Wechsel von Java nach Groovy ist in nur wenigen Stunden erfolgt. Danach ist man mindestens genauso produktiv wie mit einem Java-basierten Testframework.

Die Spock Groovy DSL gibt die möglichen Strukturen der Tests klar vor, sie folgt dabei im Wesentlichen einer given-when-then-Notation, wie man sie aus dem Behaviour-driven Development (BDD) kennt. Spock stellt den korrekten Testaufbau sicher und prüft die korrekte Reihenfolge der einzelnen Phasen. So ist es mit Spock nicht möglich, einen Test zu schreiben, der keine einzige Assertion enthält. In Abbildung 1 sind die unterstützten Phasen und Blocks dargestellt.

reimer_spock_1.tif_fmt1.jpgAbb. 1: Blocks und Phasen eines Spock-Tests

Die erste Außenmission mit Spock

Um Spock in einem Projekt zu verwenden, müssen lediglich einige wenige Dependencies über das bevorzugte Build-Tool hinzugefügt werden (Listing 1). Die Spock Core Dependency wird zwingend benötigt, die anderen Dependencies sind optional.

Listing 1: Dependencies hinzufügen

// choose Spock with desired ...

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