Self-Healing darf einen echten Bug nicht unsichtbar machen.
Ein grüner Test ist nur dann gut, wenn er weiterhin das Richtige prüft. TestZombie soll geeignete Probleme bei der Element-Suche beheben, nicht fehlgeschlagene fachliche Prüfungen überdecken. Deshalb bleiben unsichere Fälle sichtbar und Reparaturen nachvollziehbar.
Vier Prinzipien für vertrauenswürdiges Self-Healing.
Ein Test sollte nur dann weiterlaufen, wenn genügend Hinweise für das ursprünglich gemeinte Element sprechen. Bei unsicheren Treffern muss der Fehler sichtbar bleiben, damit dein Team ihn prüfen kann.
Locator-Probleme von Produktfehlern trennen
Healing adressiert technische Element-Zuordnung – nicht fachliche Assertions oder echte Anwendungsfehler.
Unsicherheit sichtbar lassen
Wenn kein belastbarer Kandidat existiert, ist ein roter Test besser als ein falscher grüner Test.
Healing nachvollziehbar machen
Original-Locator, Ersatz und Kontext sollten für Team und Review sichtbar bleiben.
Dauerhafte Fixes kontrollieren
Automatic Code Update soll in normale Git- und Review-Prozesse passen, statt Änderungen zu verstecken.
Was Healing lösen sollte – und was nicht.
Eine klare Grenze hilft Teams, TestZombie als Wartungsautomatisierung statt als Fehler-Unterdrückung einzusetzen.
- ID, CSS, XPath, Rolle oder Accessibility-Identifier geändert
- Element befindet sich nach UI-Refactoring an einer neuen Position
- Technischer Locator ist veraltet, der fachliche User Flow bleibt gleich
- Assertion oder erwartetes Business-Ergebnis ist falsch
- Ziel-Element existiert fachlich nicht mehr
- Mehrere Kandidaten sind zu ähnlich und nicht sicher zuzuordnen
FAQ zu sicherem Self-Healing
Sollte Self-Healing jeden Testfehler reparieren?
Nein. Self-Healing ist besonders für technische Locator- und UI-Drift geeignet. Fachliche Assertions und echte Produktfehler sollten sichtbar bleiben.
Was passiert bei mehreren möglichen Ziel-Elementen?
Wenn die Zuordnung nicht ausreichend sicher ist, sollte der Test fehlschlagen oder in einen Review-Fall gehen, statt willkürlich weiterzulaufen.
Warum ist Automatic Code Update Teil der Trust-Story?
Weil erfolgreiche Healings dadurch nicht dauerhaft unsichtbar im Runtime-Layer bleiben. Der Fix kann sichtbar, reviewbar und wartbar in den Testcode überführt werden.