Ein Programmierer sieht rot: Was tun bei fehlerhaften JUnit-Tests?

Eine fiktive Fallstudie

Das Einfachste wäre sicherlich gewesen, alles wegzuschmeißen, was nicht läuft. Allerdings gibt es einige einfache Tricks, wie man die Tests vorerst noch behalten kann, um sie sich für spätere Fälle aufzuheben. Schauen wir uns dazu das folgende Listing als fiktives Beispiel mit folgender Testmethode zur Überprüfung hochkritischer Verschlüsselungsroutinen an [1]:

@Test
public final void testCryptBillsFile() throws IOException {
    File tempFile = new File("C:/Temp", "billsfile.txt");
    checkCrypt(tempFile);
}

Dummerweise steigt dieser Test auf meinem Rechner immer mit einer FileNotFoundException aus, deren Ursache sich mir noch nicht erschließt. Der erfahrene Programmierer erkennt hier natürlich sofort, dass der verwendete Pfad betriebssystemabhängig ist und auch unter Windows nicht unbedingt in C:/temp vorhanden sein muss. Was tun wir also mit dem Test? Repararieren? Aber wie? Wegschmeißen? Damit tut man sich als Entwickler erfahrungsgemäß schwer. Und vielleicht taucht Bill, der ursprüngliche Autor, ja doch noch aus dem Exil auf und kann uns bei der Reanimation des Tests weiterhelfen. Solange wir nicht wissen, was wir mit dem Test machen sollen, bleiben uns folgende Alternativen:

  • Testmethode auskommentieren
  • nur @Test auskommentieren oder löschen (JUnit 4)
  • mit @Ignore markieren (JUnit 4):
@Ignore
@Test
public final void testCryptBillsFile() throws IOException {
    ... 
}

Die Empfehlung hier lautet: Verwende @Ignore, das von JUnit 4 bereitgestellt wird, aber den meisten Entwicklern nicht bekannt ist. Damit taucht testCryptBillsFile()noch in der Liste der angezeigten Tests auf (und bleibt so hoffentlich in Erinnerung), wird aber nicht ausgeführt (Abb. 2).

Abb. 2: Ignorierte JUnit-Tests

Was macht man aber, wenn man noch mit JUnit 3 arbeitet, was in vielen (vor allem älteren) Projekten noch im Einsatz ist? Auch hier kann man die JUnit-4-Bibliothek und die @Ignore-Annotation einsetzen. Falls das nicht möglich ist, empfiehlt es sich, die Methode durch ein vorangestelltes broken umzubenennen, in unserem Fall also in brokentestCryptBillsFile(). Zwei Fliegen haben wir damit geschlagen:

  • die Methode wird nicht mehr von JUnit 3 ausgeführt (kein test-Prefix)
  • die Methode wird als „broken“ gekennzeichnet.

Auch wenn damit die Tests noch nicht repariert sind, kommt man damit doch wieder auf einen grünen Testbalken, den es zu verteidigen gilt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.