Obwohl Java und das dazugehörige Ökosystem an Entwicklungsumgebungen, Frameworks, Bibliotheken und Standards nun schon viele Jahre existieren, taucht hin und wieder eine einfache Idee auf, die die Arbeit wesentlich angenehmer gestaltet. Das ist auf der einen Seite Grund zur Freude und auf der anderen Seite fragt man sich: „Warum habe ich daran nicht schon selbst gedacht?“ Eine dieser Ideen ist FEST. Das erste, das an dieser Library auffällt, ist der Name: Der bleibt auf jeden Fall im Gedächtnis. Und das ist gut so, denn schon nach den ersten Zeilen Testcode will man das Jar nicht mehr im seinem Classpath missen. Aber der Reihe nach: Worum geht es eigentlich?

Tests schreiben heißt Erwartungen formulieren

Dieses Szenario kommt leider allzu oft vor: Man hat die Aufgabe, eine bestehende Funktionalität anzupassen und findet eine hohe Testabdeckung vor. Wenn man versucht, die Tests anzupassen, die die gewünschte Funktionalität beschreiben, gibt es allerdings ein Problem: Der Grund dafür ist, dass der Autor keinen Wert darauf gelegt hat, seine Tests so zu gestalten, dass klar wird, welche Anforderungen sie formulieren. Oft bleibt dann nur die Möglichkeit, den Produktionscode zu verändern, um zu identifizieren, welche Tests nun fehlschlagen, um herauszufinden, wo und ob das zu verändernde Verhalten getestet wird. Diese dann anzupassen, ist ein mühsames Unterfangen.

Eine solche Episode zeigt, dass Tests, die nicht klarmachen, welches Verhalten vom Code erwartet wird, ein Problem sind: Sie ermöglichen eben nicht die sichere Anpassung von Produktionscode, die agile Softwareentwicklung überhaupt erst ermöglicht. Mit der Zeit wurden viele Features in JUnit realisiert, die dem Nutzer helfen sollen, diesen Fehler zu vermeiden. Irgendwann fand man als JUnit-User plötzlich Klassen mit einem anderen Paketnamen in den JUnit-Abhängigkeiten vor: Hamcrest war da!

Hamcrest

Die Hamcrest Matcher beseitigten ein Problem beim Testen: Mit (JUnit-)Bordmitteln sieht ein Assert nämlich so aus:

assertEquals(actualOutcome, expectedOutcome);

Beim Schreiben solcher Asserts gab es eigene Probleme:

• Man hatte nur eine sehr eingeschränkte Möglichkeit zum Vergleich.
• Die Parameterreihenfolge wurde oft durcheinandergebracht.

Beide Probleme wurden durch Hamcrest beseitigt. Plötzlich konnte man sehr anschaulich Erwartungen beschreiben:

assertThat(actualOutcome, equalTo(expectedOutcome));

Allerdings hat die API einen Haken: Damit man flüssig mit der Library arbeiten kann, muss man die verschiedenen Matcher kennen. Und davon gibt es so einige.  Und selbst wenn man sich in der Hamcrest Library so einigermaßen zurechtfindet: Wenn in einem Projekt zusätzliche Matcher geschrieben werden (was eine gute Idee ist), werden diese oftmals nicht benutzt, weil sie einfach nicht jedem Entwickler bekannt sind.

FEST

Genau dieses Problem beseitigt FEST, indem es auf das Konzept eines Fluent Interface zurückgreift. Was dabei herausgekommen ist, ist meiner Meinung nach nicht nur noch deutlicher:

order.addItem(firstItem);
assertThat(order.getAllOrderItems()).containsExactly(firstItem);

sondern die IDE teilt nun auch mit, welche Vergleichsoperationen möglich sind!

Am Ende soll nicht verschwiegen werden, dass FEST sowohl in der Version 1.4 als auch in der Version 2.0 nicht mehr aktiv weiterentwickelt wird. Die Zukunft gehört dem Fork AssertJ. Die Idee ist aber die gleiche geblieben, und darüber hinaus gibt es einige ergänzende Projekte, die einen Blick wert sind, wie z. Bsp. Asserts für besonders populäre Bibliotheken wie Joda-Time oder Google Guava.