Matching Expectations

Es ist Sommer! Also ab in die Eisdiele und im besten Pseudo-Italienisch „Una Tschokkolatta per fawor!“ bestellen – doch was gibt es statt der leckeren braunen Schokoladenoffenbarung in einer knusprigen handgerollten Waffel? Eine rosa „Einhorn“-Eis-Scheußlichkeit mit Marshmallowklumpen in einem Pappbecher. Eine weitere schöne Urlaubserinnerung runiniert durch mangelhafte Unit-Tests. Moooment. Wie bitte? Nein, dies wird kein Bericht über meinen letzten Urlaub. Guckt mal da drüben. Heute möchte ich darüber schreiben, wie man Erwartungen in Unit-Tests abprüfen kann.

Eis!

Das Erlebnis aus der Eisdiele soll dabei als Beispiel dienen. Also modellieren wir unser Eis:

Dann brauchen wir noch ein Behältnis, damit die Kugel nicht durch die Finger flutscht:

… und schließlich den Auslöser für unser Trauma, das Trio Infernale der Eisverkäufer – je mit einem eigenen Verständnis, wie so ein Eis auszusehen hat:

Verkostung

Dann wollen wir mal unsere Erwartungen formulieren:

Ein netter kleiner Unittest. Aber es fällt schwer zu sehen, was genau wir hier testen – zumindest mir, und ich hab’s gerade erst geschrieben. Was hat uns Onkel Bob zu Sachen gesagt, die wir gerade geschrieben haben? Schaut, ob ein wenig Refactoring sie verbessern kann! Also erst mal raus mit diesem grausigen Farbtest in eine eigene Methode – und wenn wir schon mal dabei sind könnten auch die Prüfungen für Behälter und Stückchen etwas eloquenter ausfallen:

So. Gleich viel besser. Mal schaun, wie’s mit einer größeren Bestellung läuft – dem berühmten „Tricolore“-Becher in den italienischen Nationalfarben Grün, Weiß und Rot, repräsentiert durch Pistazieneis mit kleinen knusprigen Pistaziensplittern, einer schön sauren Kugel Zitroneneis (keine fancy Zitronenschalenzesten bitte) und Erdbeereis aus echten Erdbeeren, so dass noch ein paar weiche Erdbeerstückchen darin sind. Und nachdem wir unseren Kindern nicht zutrauen, drei Kugel auf einer Waffel zu balanzieren, ohne dass sie schmelzen oder auf T-Shirt oder Fußboden landen, bitte in einem stabilen Plastikbecher, der weder zerdrückt wird noch durchweicht. Sch*** auf die Umwelt, wir schreiben hier Unittests…

Da wiederholt sich aber ganz schön viel Code. Kann mir bitte jemand den Unterschied zwischen den Tests der einzelnen Kugeln zeigen? Alles was ich hier sehe ist Boilerplate-Code. Was sagst du, Bob?

Besser. Jetzt sehe ich die Unterschiede viel klarer. Nur die Farbprüfung musste außen vor bleiben, weil das jeweils ein anderer Assert ist und wir in unserer assertScoop keine Switch-Case-Orgie starten wollen. Und die Überpfüfungslogik kann man schließlich nicht herumreichen… na gut. Mit Java 8 und Lambdas geht das sogar halbwegs lesbar:

Und wenn es nur um Eis ginge würde ich hier vermutlich auch aufhören und mich darauf konzentrieren der Prinzessin beizubringen, dass nicht jeder fluffiges Einhorneis möchte. Oder ein paar BuilderFactoryProvider schreiben um das servieren der Eisbecher zu vereinfachen. Aber ich wollte was über Tests erzählen und du hast noch nicht weggeklickt, also führen wir den Test mal aus:

Was genau lief hier verkehrt? Keine Ahnung ohne in Zeile 113 der Testklasse nachzusehen:

Wir können dem Assert noch einen Text für den Fehlerfall mitgeben,

aber wer will schon immer wieder das gleiche in Prosa und Code schreiben (geschweigedenn bei einem Refactoring anpassen)? Sollte ich neben meinen selbst geschreibenen Asserts noch einen Pool von String-Konstanten oder -Buildern anlegen? Oder könnte ich vielleicht das Wissen, wie etwas geprüft wird und wie eine Abweichung davon dargestellt wird in ein Objekt verpacken? Lasst uns dieses Objekt Matcher nennen. Und bevor wir es schreiben, mal kurz schauen, ob das vielleicht schon jemand für uns gemacht hat. Tatsache. JUnit (genauer gesagt das damit ausgelieferte Hamcrest) bietet Matcher und passende Basisklassen für eigene Implementierungen. Also frisch ans Werk und ein paar eigene Matcher geschrieben:

Matcher

Erst mal ein Matcher für Farben, der die kruden R/G/B-Vergleiche hinter netten Labels versteckt:

Und noch ein paar Konstanten für unsere Farben:

Natürlich können wir diesen Matcher in einem anderen Matcher wiederverwenden und genau wie zuvor die Lambdas durchreichen.

Bei der Verwendung von Matchern ist es üblich, die Assertions im Stil assertThat(x, is(matcher)) zu schreiben:

Natürlich können wir auch einen Matcher für die Waffel schreiben;

…aber der Testcode könnte besser aussehen. Was soll das true überhaupt bedeuten? Hamcrest’s CoreMatchers bietet viele statische Methoden zur Erzeugeung passender Matcher an, das sollten wir auch tun:

Nachem jetzt unsere Matcher mit einer lesbaren Beschreibung glänzen sollten wir auch unseren Objekten eine oredentliche toString-Methode verpassen, um statt so was

das zu erhalten:

Aber warum übergeben wir unserem ScoopMatcher immer noch zwei mal null? Oder im Fall der „Tricolore“ – wer weiß beim nächsten Blick auf den Code noch, warum hier zwei mal "strawberry" übergeben wird? War der erste oder zweite String der Geschmack der Stückchen? Können wir nich einfach sprechende Matcher für alle Eigenschaften unseres Eisbechers schreiben und die kombinieren? CoreMatchers.allOf(Matcher<? super T>...) macht genau das – es kombiniert alle Matcher zum gleichen Objekt und prüft, ob alle zutreffen. Aber wir wollen eigentlich nicht jedes Mal den kompletten Eisbecher Matchen, sondern einzelne Eigenschaften. Den Code, um diese Eigenschaften vom Ganzen abzufragen und mit einem passenden Matcher zu prüfen können wir in eine eigene Basisklasse auslagern:

…und damit Farbe und Geschmack prüfen:

Jetzt noch diese Matcher in eigenen Methoden erzeugen:

Wir können auch einen Matcher für die Stückechen zusammenstellen:

Ja, auch die Matcher für Konsistenz und Geschmack der Stückchen könnten noch mit eingenen Methoden erzeugt und reingereicht werden, aber ob das die Lesbarkeit weiter verbessert bezweifle ich in diesem Fall.

Gehen wir noch einen Schritt weiter und verpacken die Listen-Prüfungen so, dass wir die Kugel-Matcher direkt auflisten:

Fast fertig. Jetzt noch die Matcher für Behälter und Inhalt vereinen und das ganze liest sich wie ein Satz:

Jetzt sehen wir auch endlich deutlich, was Luigi falsch gemacht hat:

Das ist leider nicht die ganze Wahrheit, denn Luigis Zitroneneis ist auch zu gelb, aber Hamcrest’s allOf beendet die Prüfung nach dem ersten Fehler, so dass man potentiell von Fehler zu Fehler stolpert statt alle auf ein Mal zu sehen. Hier könnte man sich einen eigenen kombinierenden Matcher schreiben, der alle Kinder immer ausführt, die Ergebnisse in der Methode matches sammelt und in describeMismatch ausgibt.

Zusammenfassung: (Wann) sollte ich Matcher verwenden?

Matcher helfen bei zwei Aspekten:

  • Wiederverwendung von Testcode
  • Lesbarkeit von Tests

und das mit gut lesbaren Fehlermeldungen. Es ist etwas mehr Aufwand als für den ersten Testfall ein paar Asserts runter zu hacken und diese dann per Copy’n’Paste wieder zu verwenden, aber wenn man die Tests nach einer Weile wieder bearbeiten und verstehen muss macht sich der Aufwand bezahlt.
Und natürlich ist es mindestens genau so wichtig das Test-Setup lesbar zu gestalten. Wenn man auf einen Blick sehen kann, was in einem Test geschieht und wie er sich von seinen Nachbarn unterscheidet kann man mehr Zeit zur Behebung der Eis-Bugs aufbringen statt sich durch alten Spaghetti-Test-Code zu wühlen.

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*