Zur Entwicklung korrekter Unit Tests gibt es zwei ganz unterschiedliche Motivationen. Die ehrenhafte, der Entwickler möchte seinen Code absichern und die andere, der Programmierer wird zum Schreiben von Tests gezwungen.
Im Beitrag Tolle Test habe ich einige Grundsätze für das Schreiben guter Unit Tests und die dabei üblichen Fehler skizziert. In diesem Beitrag möchte ich über das Anti-Pattern Poking Dead Bodies berichten. Der Name entstand, als wir im Kollegenkreis, über ein paar sehr schrullige JUnit Test scherzten.
Mit Poking Dead Bodies ist das Anstupsen toter Tiere mit einem Stock gemeint. Immer in Verbindung mit der geradezu kindischen Erregung, ob sich das Viech jetzt doch noch mal rührt oder wirklich mausetot ist.
In dieser Form des Stupsen und Gucken schreiben die, zur Produktion von Tests verdammten, Programmierer ihre Unit Test. Sie nehmen sich das Anschauungsobjekt ihrer Wahl und rufen die offensichtlichen Methoden auf und schreiben diverse Asserts für das Ergebnis.
Mit dieser Methode kann die Anzahl der Unit Tests erhöht werden, die Code Coverage des Projektes steigt vermutlich auch, aber leider ist durch diese Tests selten etwas gewonnen. Das bloße Prüfen einer Methode oder Klasse, anhand einiger fester Parametersätze, zeigt nur ein paar korrekte Pfade durch das Labyrinth der Programmabläufe. Ob der Parametersatz, in dieser Form überhaupt repräsentativ ist, für die Verwendung des Code, ist oftmals fraglich. Dafür werden andere kritische Parametersätze selten geprüft.
Ein Hinweis auf das Poking Dead Bodies Anti-Pattern ist die Abwesenheit von negativen Test und die fehlende Prüfung von Grenzsituationen in den Parametersätzen. Üblicherweise sind das die Tests, die sich mit den möglichen Exceptions einer Methode beschäftigen oder die verbotener Werte in die Berechnung einschleusen. Dies sind häufig die Werte null, Double.NaN oder Double.NEGATIVE_INFINITY.
Problematischer als das Fehlen dieser wichtigen Tests, ist die Unsicherheit, ob und was die existierenden Tests überhaupt abdecken. Im Gegensatz zum Test Driven Development werden bei Poking Dead Bodies die Tests nachträglich hinzugefügt. Beim Test Driven Development wird zuerst der Test geschrieben und danach die Implementierung erstellt. Daher scheitern die Tests zu Beginn und werden erst erfolgreich, wenn die Implementierung der Funktionalität den Anforderungen der Tests entspricht. Bei Poking Dead Bodies bastelt der Entwickler aber so lange an seinen Asserts herum, bis der Test irgendwann erfolgreich durchlaufen wird. Statt eines guten Test kann der Entwickler aber auch zwei andere Dinge damit konstruieren. Einen Test, der einen offensichtlichen Implementierungsfehler fälschlicher Weise positiv prüft, oder einen Test mit Pseudo-Asserts, die eigentlich gar nichts machen, weil die Prüfung Fehler enthält.
Der beste Schutz gegen Poking Dead Bodies ist die Erstellung von Unit Tests anhand definierter Use Cases und dies, optimaler Weise, bevor die Implementierung geschieht.