Unit-Test

Ein Unit-Test prüft einen Baustein für sich, ohne Datenbank, Dateisystem oder Netz – deshalb läuft er in Millisekunden, und ein Fehlschlag zeigt sofort die schuldige Stelle. Ein Integrationstest prüft das Zusammenspiel zweier Bausteine und braucht dafür die echte Umgebung; umfangreichere Läufe brauchen dann Minuten statt Millisekunden. Daraus folgt eine Grenze: Eine grüne Unit-Test-Suite sagt nichts darüber, ob zwei für sich korrekte Bausteine miteinander reden. Schnittstellenfehler entstehen erst im Zusammenspiel und bleiben in der Isolation unsichtbar.

Die Testpyramide nach Mike Cohn nennt als Zielverteilung etwa 70 Prozent Unit-Tests, 20 Prozent Integrationstests und 10 Prozent Tests über die ganze Oberfläche. Die Begründung ist rechnerisch: Nur die schmale Spitze braucht Browser, Datenbank und Wartezeiten. Kippt das Verhältnis, entsteht der Eiscreme-Kegel – als Lehrbeispiel dienen 500 Oberflächentests neben 50 Unit-Tests. Eine solche Suite läuft Stunden statt Sekunden und wird deshalb vor einer Änderung nicht mehr gestartet.

Ein Unit-Test, der ohne Codeänderung zwischen grün und rot wechselt, richtet mehr Schaden an als kein Test: Das Team gewöhnt sich daran, Rot zu übersehen, und übersieht damit auch echte Fehlschläge. Solche Wackelkandidaten heißen Flaky Tests; Ursache sind meist Uhrzeit, Zufallswerte, Ausführungsreihenfolge oder echte Netzzugriffe. Die Regel lautet: sofort stilllegen, Ursache beheben oder den Test löschen. Ein stillgelegter Unit-Test behauptet nichts, ein wackelnder behauptet jeden zweiten Lauf etwas anderes.

Ein Unit-Test prüft die Umsetzung statt das Verhalten, wenn er rot wird, obwohl das Ergebnis stimmt – etwa nach einer Umbenennung oder weil eine Methode nun zweimal statt einmal aufgerufen wird. Fachlich heißt das hohe Kopplung zwischen Test und Umsetzung. Die Folge ist teuer: Jedes Aufräumen im Code erzeugt Testarbeit, und genau dieses Aufräumen unterbleibt dann. Die Regel dagegen: Eine Zusicherung beschreibt das Ergebnis, nicht den Weg dorthin. Ausnahme bleiben Aufrufe mit Außenwirkung wie ein Mailversand.

Eine Unit-Test-Suite, die seit Monaten nicht gelaufen ist, sichert zunächst nichts ab. Ungenutzte Suiten sind fast immer rot: Abhängigkeiten sind weitergezogen, Testdaten passen nicht mehr, einzelne Fälle prüfen längst entfernte Funktionen. Bei einer Projektübernahme steht deshalb ein vollständiger Lauf vor der ersten Änderung, samt notierter Laufzeit. Erst eine grüne Suite ist ein Sicherheitsnetz. Eine rote ist eine Sammlung von Behauptungen über einen Zustand, den es nicht mehr gibt – und niemand weiß, welche davon noch gilt.

Das Verfahren heißt Mutation Testing und ist seit fast 50 Jahren bekannt. Ein Werkzeug verändert den Quellcode an vielen Stellen minimal – aus größer wird kleiner, aus plus wird minus – und lässt danach die Tests laufen. Jede Veränderung, die keinen Test rot macht, ist eine Lücke. Der Anteil der bemerkten Veränderungen heißt Mutation Score. Die Grenze: Der Score bewertet die Tests gegen den vorhandenen Code, nicht gegen die Anforderung. Eine falsch umgesetzte Regel bleibt unentdeckt.