Hier soll es in der Tat darum gehen, vor allem die Qualität von Tests zu untersuchen.

Denn alleine mit der Testerei und einer sehr hohen Testabdeckung ist noch nichts gewonnen. Unwartbare, schwer zu pflegende oder migrierende Tests machen Entwicklern unter Umständen das Leben so schwer, dass sie hinten runterfallen.

Deshalb möchte ich hier peu-à-peu Test-Patterns und Test-Anti-Patterns vorstellen, die natürlich allesamt im Netz schon zu finden sind, dokumentiert und/oder besprochen wurden oder aus meinem privaten Erkenntnisprozess entstanden.

Die Bezeichner für die Muster dienen natürlich der Kommunikation über die Patterns, im Falle dass man sie in eigenem Code oder Projekt wiederfindet.

Test Anti Patterns

The Local Hero

Wir haben dieses Pattern, was sich eigentlich auf jede Form von Code(konstrukten) beziehen kann, bei uns im Projekt BMG-Pattern getauft. Wann immer in eurem Projekt der Satz auftaucht: „Also, bei mir geht’s“, solltet ihr wissen, dass ein Hero vor euch steht, aber eben „nur“ ein Local Hero.
Was auch immer eingecheckt oder fabriziert wurde, es hängt von lokalen Umständen, speziellen Build Befehlen oder anderen Jedi-Moves ab, die Software zum Laufen zu bringen.

Ursache

In vielen Testfällen hat man Abhängigkeiten zu externen Daten und Properties. Oftmals werden Tests ohne direkte Kenntnisnahme dieser Abhängigkeiten geschrieben und laufen grün.
In schwierigen oder komplexen Fällen haben die Kollegen die gleichen Voraussetzungen und keiner merkt die Abhängigkeit. Dann könnte man sogar zu „The Project Hero“ werden.

Beispiel

Ein einfacher Test, der „bei mir grün“ wird, sieht wie folgt aus:


@Test
public void testMyDefaultLocaleIsGermany() {
assertThat(Locale.getDefault(), is(Locale.GERMANY));
}


Wird er das auch bei euch?
Wenn ja, willkommen in meinem Land. Wenn nein, upps, sorry therefore I’ve missed correct configuration.

Bitte keinen Aufschrei, welch ein Unsinn so etwas zu testen, denn indirekt haben wir (vermutlich „alle, bis auf endlich viele“ (Zitat meines Analysis-Professors)) diesen Fehler schon einmal gemacht.
Ich habe gerade aktuell in meinem Projekt den Fall, dass diese Unschärfe basierend auf dem Standardlocale einen Test rot laufen ließ, der vom Continous Integration Build-Server bereits erfolgreich abgehakt wurde.
Per Zufall war ich der einzige, der ein anderes Locale eingestellt hatte, als die Kollegen.

Problembeseitigung

Das Problem ist schnell beseitigt, wenn man es denn findet. Es tritt nämlich erst beim Buildserver oder gar beim nächsten Update eines Kollegen auf.

Dann lassen sich solche Vorbedingungen sehr schön in eine testspezifische setUp-Methode packen:


@Before
public void setUp() {
Locale.setDefault(Locale.JAPANESE);
}

@Test
public void testMyDefaultLocaleIsGermany() {
assertThat(Locale.getDefault(), is(Locale.JAPANESE));
}