Ein roter Test in der Pipeline, und ein Agent bringt ihn wieder zum Laufen: Der Healer aus Playwrights Agentenfamilie reproduziert den Fehlschlag, wertet die Artefakte aus, sieht sich die aktuelle Oberfläche an und schlägt eine Änderung vor. Das spart echte Zeit — der Klassiker, dass eine Schaltfläche umbenannt wurde und zwölf Tests deshalb brechen, ist in Minuten erledigt.
Der Satz aus der Dokumentation, den man gelesen haben sollte
Hält der Healer die Funktionalität für defekt, kann er den Test auch überspringen. Und ein übersprungener Test sieht im Report aus wie ein bestandener Lauf. Wer nur auf die Farbe der Pipeline schaut, merkt nicht, dass gerade ein Stück Absicherung verschwunden ist.
Erst klassifizieren, dann anfassen
Nicht jeder rote Test ist ein kaputter Test. Fünf Fehlerklassen kommen infrage — und nur zwei davon rechtfertigen es, den Testcode zu ändern:
- Geänderter Locator oder Timing-Problem — hier darf ein Agent arbeiten.
- Testdaten oder Umgebung — dann repariert man die Umgebung, nicht den Test.
- Echte Regression — dann ist der rote Test das gewünschte Ergebnis.
- Veraltete Erwartung — erst die Anforderung klären, dann alles andere.
Die Grenze ist einfach zu ziehen
Ein sicherer Patch ändert den Weg zum Ziel, nie die Aussage: Locator statt CSS-Klasse, Web-first Assertion statt fester Pause. Wer einem Agenten erlaubt, Assertions abzuschwächen, bekommt garantiert eine grüne Suite — und verliert genau das, wofür sie da war.
Mehr dazu im Seminar
Fehlerklassen, Guardrails und eine Reparatur mit Nachweis übt das Modul Fehlgeschlagene Tests sicher reparieren — mit Video und Kapitelübersicht. Den Ablauf davor, von der Erkundung bis zum erzeugten Testcode, behandelt das Seminar Playwright mit KI-Agenten.