Fehlgeschlagene Tests sicher reparieren

Fehlgeschlagene Tests sicher reparieren

0:00 Selbstheilende Tests — das klingt nach dem Ende einer lästigen Pflicht. Und tatsächlich kann der Healer erstaunlich viel: Er reproduziert einen Fehlschlag, sieht sich die Oberfläche an, schlägt eine Änderung vor und probiert sie aus. Nur gibt es eine Sache, die er nicht kann, und die ist entscheidend: unterscheiden, ob der Test falsch liegt oder das Produkt.

0:20 Deshalb geht es in diesem Modul weniger um die Bedienung des Healers als um die Regeln, unter denen man ihn arbeiten lässt. Sonst wird aus Selbstheilung schleichender Qualitätsverlust.

Mit dem Healer-Agenten arbeiten

0:31 Zuerst der Ablauf: Was passiert in einer Healer-Schleife, und wie führt man sie so, dass am Ende ein nachvollziehbares Ergebnis steht? Der Healer ist der Agent, der am meisten Aufsehen erregt und die klarsten Regeln braucht. Wir schauen uns erst an, was er tatsächlich tut — und danach, was er auf keinen Fall tun darf. Der Healer führt die Suite aus und nimmt sich fehlgeschlagene Tests vor: Er reproduziert den Fehler, wertet die Artefakte aus, schaut sich die aktuelle Oberfläche an, schlägt eine Änderung vor und führt den Test erneut aus.

1:02 So weit, so gut. Und dann steht in der Dokumentation ein Satz, den man gelesen haben sollte: Hält er die Funktionalität für defekt, kann er den Test auch überspringen. Ein übersprungener Test sieht im Report aus wie ein bestandener Lauf — genau deshalb braucht dieser Ablauf feste Regeln. Fünf Schritte, und der erste ist eine Selbstbeschränkung: genau einen fehlgeschlagenen Test benennen. Nicht die Suite.

1:25 Dann die Reproduktion abwarten und den Fehlertext mit den Artefakten zusammen lesen. Dann — und das ist der Kern — die vorgeschlagene Ursache prüfen, bevor die Änderung entsteht. Dann den Diff ansehen: Betrifft er den Locator oder die Erwartung? Diese Unterscheidung entscheidet über alles Weitere. Und zuletzt erneut ausführen und mit dem Plan abgleichen.

1:47 Klingt umständlich, dauert aber keine zehn Minuten. Drei Befehle für die Vorarbeit. Der erste wiederholt einen Test mehrfach — damit trennen Sie einen echten Fehlschlag von einem launischen. Der zweite führt genau einen Test aus und schaltet die Trace-Aufzeichnung ein. Der dritte öffnet den Trace. Merken Sie sich vor allem den ersten: Ein Fehlschlag, der sich nicht reproduzieren lässt, ist kein Reparaturfall, sondern ein Stabilitätsfall.

2:14 Den Healer darauf loszulassen, ist ungefähr so sinnvoll, wie einen Handwerker zu rufen, weil es gestern getropft hat. Der erste Punkt ist der wichtigste, und er ist unangenehm logisch: Ein Agent, der Assertions ändern darf, macht jeden Test grün. Nicht aus Böswilligkeit, sondern weil das die einfachste Lösung der gestellten Aufgabe ist. Er wurde ja gebeten, den Test zum Laufen zu bringen.

2:38 Ohne Grenze wandert die Reparatur außerdem gern in den Produktivcode. Mehrere Runden ohne Abbruchregel kosten Kontext und verwischen die Ursache. Und übersprungene Tests verschwinden lautlos aus der Absicherung. Deshalb: Regeln zuerst, Schleife danach. Vier Fehler, die in der Praxis teuer werden. Die ganze Suite auf einmal heilen zu lassen erzeugt einen Diff, den niemand mehr liest — und damit genau die Situation, die wir vermeiden wollen.

3:06 Änderungen zu übernehmen, ohne die Ursache benennen zu können, ist die Definition von Symptombehandlung. Den Healer zu starten, obwohl die Umgebung das Problem ist, führt zu Reparaturen an völlig gesunden Tests. Und direkt auf den Hauptzweig zu schreiben nimmt Ihnen die einzige Stelle, an der so etwas auffällt.

Fehlschläge einordnen, bevor repariert wird

3:24 Damit kommen wir zum eigentlichen Handwerk dieses Moduls: der Klassifikation. Sie entscheidet, ob überhaupt jemand den Testcode anfassen darf. Dieses Kapitel ist kurz und trägt trotzdem das ganze Modul. Wer die Klassifikation beherrscht, kann Healing gefahrlos einsetzen; wer sie überspringt, baut sich still eine grüne Fassade.

3:44 Fünf Fehlerklassen genügen, und die Zuordnung dauert selten länger als ein paar Minuten. Nicht jeder rote Test ist ein kaputter Test. Das klingt trivial und wird trotzdem täglich ignoriert, weil Rot in der Pipeline sich anfühlt wie ein Defekt, den man wegmachen muss. Bevor eine Änderung entsteht, wird der Fehlschlag deshalb einer Klasse zugeordnet — und nur zwei dieser Klassen rechtfertigen es, den Test anzufassen.

4:09 Bei einer echten Regression ist der rote Test das gewünschte Ergebnis. Er tut genau das, wofür er geschrieben wurde. Ihn zu reparieren hieße, den Rauchmelder abzuschalten, weil er piept. Die Tabelle ist die wichtigste dieses Moduls, deshalb die Logik dahinter: Nur die ersten beiden Zeilen sind Fälle für eine automatische Reparatur.

4:29 Ein geänderter Locator und ein Timing-Problem betreffen den Weg zum Ziel, nicht das Ziel selbst — hier darf ein Agent arbeiten. Die unteren drei Zeilen brauchen eine Entscheidung von Menschen: Bei Testdaten oder Umgebung repariert man nicht den Test, sondern die Umgebung. Bei einer echten Regression bleibt der Test rot. Und bei einer veralteten Erwartung muss erst die Anforderung geklärt werden, bevor irgendetwas geändert wird.

4:54 Hier ist das Schadensmuster in vier Schritten. Eine geänderte Assertion macht aus einem Produktfehler ein grünes Ergebnis. Der Agent sieht die neue Oberfläche und hält sie für richtig — er hat ja keine andere Referenz. Ein übersprungener Test sieht im Report aus wie ein bestandener Lauf. Und wer nur die Farbe der Pipeline beobachtet, merkt den Verlust nie. Das Tückische daran: Jeder einzelne Schritt ist nachvollziehbar und gut gemeint.

5:20 Erst zusammengenommen ergibt sich eine Testsuite, die nichts mehr absichert und trotzdem grün ist. Belegen heißt: nicht raten. Fehlertext und Trace zusammen lesen, nicht nur die Meldung — die Meldung sagt oft nur, dass etwas nicht gefunden wurde. Prüfen, ob das erwartete Element noch existiert und wie es jetzt heißt; sehr häufig ist das schon die ganze Geschichte.

5:42 Netzwerk und Konsole ansehen, denn manche Fehlschläge kommen aus dem Backend. Den letzten Produktivstand gegen den letzten grünen Lauf halten. Und dann die Klasse im Pull Request notieren, bevor die Änderung entsteht — das ist die Stelle, an der die Disziplin sichtbar wird.

Sichere Muster für Selbstreparatur

5:59 Bleibt die Frage, wie eine Reparatur aussehen darf, damit sie im Team tragfähig ist. Die Antwort passt in einen Satz — und in eine Tabelle. Aus den Erfahrungen der letzten beiden Kapitel wird jetzt ein Satz Regeln, den man einem Team und einem Agenten gleichermaßen geben kann. Sie sind kurz genug, dass man sie sich merkt.

6:18 Der Satz lautet: Die Absicht des Tests bleibt unverändert, nur der Weg dorthin wird angepasst. Ein Bild dazu: Wenn die Straße zur Baustelle gesperrt ist, nehmen Sie eine andere Route — aber Sie fahren nicht woanders hin. Änderungen bleiben klein und nachvollziehbar, sie durchlaufen dieselbe Prüfung wie jeder andere Code, und jeder übersprungene Test hinterlässt eine Spur.

6:39 Wenn Sie nur diese drei Bedingungen durchsetzen, ist Healing im Alltag ein echter Gewinn statt eines Risikos. Vier Merkmale, die man im Diff sofort sieht. Der Patch ändert Locator oder Wartestrategie, nicht die behauptete Aussage. Er ist in wenigen Zeilen lesbar und begründet. Er lässt die Testnamen unangetastet — daran hängt die Historie, und ein umbenannter Test verliert seine Vergangenheit.

7:03 Und er kommt mit einem Lauf, der vorher rot und nachher grün ist. Dieser letzte Punkt klingt selbstverständlich und wird trotzdem oft weggelassen; ohne ihn wissen Sie nicht, ob der Patch das Problem behoben oder nur verschoben hat. Schauen Sie auf die Richtung dieser Änderung. Vorher: ein Klick auf eine CSS-Klasse, zwei Sekunden Pause, eine Prüfung auf Sichtbarkeit.

7:26 Nachher: ein Klick auf die Schaltfläche mit ihrer Beschriftung und eine Prüfung auf den konkreten Wert. Der Patch senkt die Erwartung nicht ab — er hebt sie an. Aus „irgendetwas ist zu sehen" wird „dort steht dieser Betrag". Genau das ist das Muster, das Sie im Review suchen. Wenn ein Patch die Erwartung stattdessen lockert, ist er keine Reparatur, sondern eine stille Aufgabe.

7:50 Diese Tabelle gehört nicht in den Kopf der Reviewerin, sondern in die Agentendefinition — das ist die eigentliche Botschaft. Regeln, die nur mündlich existieren, gelten genau so lange, wie jemand aufpasst. Inhaltlich: Locator umstellen und feste Pausen ersetzen sind erlaubt. Einen erwarteten Wert anzupassen braucht fachliche Klärung. Eine Assertion zu entfernen ist nie erlaubt.

8:13 Und einen Test zu überspringen nur mit Ticket und Frist — sonst ist das Überspringen keine Ausnahme mehr, sondern ein Verfahren. Ihre Aufgabe: Führen Sie eine Reparatur so durch, dass die abgesicherte Aussage nachweislich erhalten bleibt. Der Pull Request enthält am Ende drei Dinge — Fehlerklasse, Diff und je einen Lauf vor und nach der Änderung.

8:34 Und es gibt eine Variante, die ausdrücklich zählt: Wenn Sie eine echte Regression finden, lassen Sie den Test rot und melden den Produktfehler. Das ist kein Ausweichen vor der Aufgabe, das ist die richtige Antwort. Wer sie gibt, hat das Modul verstanden. Vier Punkte, die alle mit dem Blick aufs Ganze zu tun haben. Übersprungene Tests nicht zu zählen führt dazu, dass Sie Ihre Abdeckung überschätzen — messen Sie sie, sie steht im Report.

9:00 Healing-Läufe automatisch zu mergen, weil die Pipeline grün ist, hebelt genau die Kontrolle aus, über die wir gesprochen haben. Häufige Reparaturen an derselben Stelle als normal hinzunehmen, verschenkt ein Signal: Dort stimmt etwas mit der Anwendung oder mit dem Test nicht. Und wer die Reparaturquote nie misst, merkt nicht, wie der Wartungsbedarf wächst.