26. Oktober 2015 | 2 min lesezeit

AssertJ – einfach lesbare Tests schreiben

AssertJ ist eine Alternative zur bekannten Hamcrest API, die in JUnit integriert ist. Die Dokumentation verspricht eine großen Menge an Assertions, hilfreiche Fehlermeldungen, besser lesbaren Code und eine nahezu perfekte Integration in die eigene IDE. Doch sind das ausreichende Gründe eine bewährte API gegen ein GitHub Projekt auszutauschen?

Die Korrektheit einer Klasse oder Methode wird üblicherweise durch den Vergleich eines Rückgabewerts oder eines Zustands mit einem Erwartungswert verifiziert. JUnit stellt für diesen Zweck die Klasse org.junit.Assert bereit. Deren statische Methoden mit dem Prefix assert prüfen eine bestimmte Bedingung und werfen bei einem negativen Ergebnis einen AssertionError, woraufhin die betroffene Testmethode als fehlgeschlagen markiert wird.

Die ursprünglich verfügbaren Assertions (assertNull, assertTrue, assertEquals) waren jedoch nur bedingt geeignet, um sauberen und lesbaren (Clean) Code zu schreiben. Dies veranlasste Joe Walnes dazu, einen neuen Assertion Mechanismus (assertThat) auf der Basis sogenannter Matcher zu entwickeln, die jeweils eine konkrete Regel abbilden, gegen die ein Wert geprüft wird. Eine Vielzahl von Matchern für unterschiedliche Aufgaben sind in der Hamcrest Bibliothek gebündelt. Ein Basisset wurde mittlerweile in JUnit integriert.

Die Verwendung beliebig schachtelbarer Matcher zielte darauf ab, komplexe und gut lesbare Ausdrücke zur Verifikation flexibel erstellen zu können. Leider stellt die Beschaffenheit der Hamcrest API jedoch eine gewisse Hürde für Neulinge dar, da oft nur schlecht erkennbar ist, welcher Matcher zum gewünschten Ergebnis führt. In der täglichen Nutzung fällt darüber hinaus vor allem das Fehlen einer Fluent-API auf.

An dieser Stelle setzt AssertJ an. Mit der Fluent-API wird ein verkettetes Aufrufen von Methoden ermöglicht und damit die Entwicklung von sauberen, lesbaren und aussagekräftigen Code gefördert. Gleichzeitig führt eine verbesserte IDE Unterstützung zu einer erheblichen Ersparnis an Schreibarbeit, da automatisch die passenden Assertions zur Vervollständigung anboten werden. Entwickler, die mit der Hamcrest API vertraut sind, spüren den Unterschied schon bei den ersten Gehversuchen mit AssertJ.

Darüber hinaus bietet AssertJ noch einige weitere interessante Features. Hin und wieder kann es hilfreich sein, dass ein Test nicht bereits beim ersten Fehler abgebrochen wird, sondern alle AssertionError gesammelt und am Ende gebündelt ausgegeben werden. Hierfür bietet AssertJ sogenannte SoftAssertions. Auch der Umgang mit Dateien und deren Inhalt kann durch AssertJ stark vereinfacht werden.

Allen Entwickler die bisher JUnit Assertions genutzt haben, und umsteigen möchten, bietet AssertJ ein Tool zur Migration und einen Leitfaden. Ein weiteres Feature von AssertJ ist die Möglichkeit domänenspezifische Assertions zu realisieren. Darauf werden wir in einem weiteren Beitrag eingehen.


1 Kommentar

  • René Frerichs

    6. November 2015

    Ich habe einen Fehler im SoftAssertion Beispiel korrigiert. Danke für den Hinweis!

Kontakt

OPEN KNOWLEDGE GmbH

Standort Oldenburg:
Poststraße 1, 26122 Oldenburg

Standort Essen:
II. Hagen 7, 45127 Essen