Du sollst ein Abrechnungsmodul umbauen, das seit zwölf Jahren läuft und keine Tests hat. Also lässt du dir welche schreiben. Zwanzig Minuten später sind vierzig Tests da, alle grün. Die Frage ist nur: Prüfen sie irgendetwas?
Festhalten, nicht bewerten
Ein Characterization Test beantwortet genau eine Frage — was tut das System heute? Er behauptet nicht, dass das Verhalten richtig ist. Er hält fest, dass es so ist, und verwandelt damit jede spätere Abweichung von einer unbemerkten Nebenwirkung in einen roten Test.
Das klingt trivial und ist es nicht, weil der Reflex dagegen arbeitet. Wenn beim Absichern eine Rundung auffällt, die offensichtlich falsch ist, will man sie geradeziehen. Genau das darf hier nicht passieren: Erst wird festgehalten, was ist. Die Bewertung ist eine spätere, eigene Entscheidung — sonst sicherst du nicht das System ab, sondern deine Meinung darüber.
Vier Arten, danebenzuliegen
Generierte Tests scheitern im Bestand auf wiederkehrende Weise. Sie schreiben fest, was der Code tun sollte, statt was er tut. Sie prüfen Belanglosigkeiten, sodass das Netz dicht aussieht und nichts fängt. Sie klammern sich an Interna, sodass jeder Umbau sie bricht. Oder sie halten einen echten Fehler unmarkiert fest — methodisch richtig, aber niemand weiß davon.
Das dritte Muster ist das teuerste. Ein Netz, das bei jedem Umbau reißt, wird nach kurzer Zeit ignoriert — und dann ist es schlimmer als keines, weil es Sicherheit vortäuscht.
Die Gegenprobe
Es gibt einen billigen Test für das Testnetz: Ändere absichtlich eine Zeile im Produktivcode und schau, ob es rot wird. Wird ein Test dabei nicht rot, prüft er nichts — unabhängig davon, wie gut er aussieht. Tests, die nichts gemerkt haben, werden ersetzt, nicht ergänzt.
Mehr dazu im Seminar
Wie man Testgrenzen findet, Zeit und Zufall beherrscht und mit Golden Master arbeitet, zeigt das Modul Characterization Tests und Sicherheitsnetz — mit Video und Kapitelübersicht. Die Raster zum Nachschlagen stehen im Cheat Sheet.