In den letzten Wochen habe ich mir einige neue Regeln beim Schreiben von JUnit Tests angewöhnt.

Kein CamelCase bei Methodennamen

In Tests können Methodennamen bei mir sehr lang werden. Sie beschreiben kurz, was die Methode macht. Dies führt dazu, dass ich bei fehlschlagenden Tests schnell sehe, was eventuell schief gelaufen ist. Lange CamelCase Namen sind allerdings sehr schwer zu lesen. Vor dem Auge verschmelzen die Buchstaben zu einer einzigen Buchstabensuppe. Ich verwende stattdessen inzwischen Unterstriche als Namenstrenner und weiche damit bewusst vom Java Standard ab. Aus einem failingRfc4180WithHeaderAndDifferentColumnCountInFirstDataRow wird ein failing_rfc_4180_with_header_and_different_column_count_in_first_data_row.

Hamcrest API

JUnit wird seit Version 4.4 mit dem Hamcrest API ausgeliefert. Durch die Assertion Methode assertThat und den Hamcrest Matchern werden Zusicherungen besser lesbar. Die Zusicherung kann wie ein Satz gelesen werden. Ein übersetzen des Kontrollflusses entfällt.

Ein Zusicherung, dass zwei Objekte gleich sind wird kann mit dem Standard-Assert assertEquals durchgeführt werden. Erster Parameter ist der erwartete Wert, zweiter Parameter ist der ermittelte Wert.

    assertEquals(erwartet, geliefert);
    assertFalse(erwartet.equals(geliefert));
    

Mit dem Hamcrest API wird dies zum intuitiver lesbaren

    assertThat(geliefert, is(erwartet));
    assertThat(geliefert, is(not(erwartet)));
    

Ich finde, dass gerade das zweite Beispiel sehr schön den Gewinn an Übersichtlichkeit demonstriert.

Weiterhin setzte ich beim Entwickeln auf default Sichtbarkeit der Methoden. Dieses Vorgehen hat sich in den letzten Jahren nicht als Problem herausgestellt. Der Vorteil: bei Composed methods und SLAP kann feingranularer getestet werden. Allerdings mache ich inzwischen derartige Methoden final, wenn die Klasse nicht schon final ist – was bei mir default bei neuen Klassen ist.

Immerhin sitzt die Bahn dick und fett in einem populären Gebäude an der Normannenstaße.

Quelle: Wikipedia