Was sind Self Healing Tests?

Self Healing Tests sind automatisierte Tests, die einen kaputten Selektor zur Laufzeit selbst ersetzen, statt rot zu werden. Ändert sich ein Button oder ein Eingabefeld, sucht das Werkzeug ein passendes Element und läuft weiter.

In Cypress gibt es Self Healing offiziell nur an einer Stelle: im Befehl cy.prompt. Normale Befehle wie cy.get oder cy.contains heilen nichts. Sie finden das Element, oder der Test schlägt fehl. Das ist Absicht, denn ein roter Test ist ein Signal.

Self Healing klingt nach weniger Wartung. Es hat aber einen Preis: Ein Test kann grün bleiben, obwohl sich das Verhalten deiner App geändert hat. Auf dieser Seite schauen wir uns an, was Cypress wirklich anbietet, wo das Risiko liegt und welche Grundlage Tests auf Dauer stabil hält.

Roland Golla ist offizieller Cypress Ambassador und arbeitet seit über 20 Jahren an Testing und Refactoring. Automatisiertes Testen gehört bei NCA seit 2013 zum Alltag. Cypress mit Cypress Cloud nutzen wir täglich in Production, zusammen mit GitHub Actions und GitLab CI. Instabile Selektoren lösen wir dort, wo sie entstehen: im Markup, in der Teststruktur und im Review.

Im Cypress.IO Workshop bauen wir mit dir eine Selektor Strategie, die Redesigns übersteht. Ganze Teams schulen wir in der Cypress.IO Remote Schulung. Wenn KI Agenten Tests pflegen sollen, setzen wir mit dem Vibe Coding Consulting klare Regeln auf, nach den NCA Agentic AI Coding Guardrails. Dazu passen Quality Gates für KI Code in der Pipeline.

Cypress listet in der Übersicht der KI Funktionen mehrere Werkzeuge: cy.prompt, Studio AI mit Vorschlägen für Assertions, Zusammenfassungen von Testabsicht und Fehlern, Testgenerierung aus UI Coverage sowie Cloud MCP und Cloud CLI für Agenten. Self Healing gehört dort ausschließlich zu cy.prompt.

So arbeitet es laut Cypress Doku:

• cy.prompt erzeugt aus Schritten in natürlicher Sprache echten Cypress Code und legt ihn im Cache ab.
• Der Cache wird zwischen Maschinen und in CI geteilt. Ein erneuter Lauf ruft das KI Modell nur auf, wenn sich Prompt oder DOM passend geändert haben.
• Passt ein gecachter Selektor nicht mehr, erzeugt Cypress den Schritt neu.
• Im Command Log steht dann Self Healed via Cache oder Self Healed via AI, mit dem Element, auf das der Schritt jetzt zeigt.

Cypress beschreibt zwei Arbeitsweisen. Entweder du exportierst den erzeugten Code und committest ihn. Dann läuft der Test ohne KI und ohne Self Healing. Oder du lässt cy.prompt im Test, und Selektoren passen sich laufend an. cy.prompt braucht Cypress Cloud, läuft nur in E2E Tests und nur in Chromium Browsern.

Ein Test hat eine Aufgabe: Er soll laut werden, wenn sich etwas Wichtiges ändert. Self Healing dreht das um. Der Test findet ein anderes Element und bleibt grün. Ob die Änderung gewollt war, prüft dabei niemand.

Ein Beispiel: Aus dem Button „Bestellen“ wird „Bestellung prüfen“, und ein Klick führt jetzt auf eine Zwischenseite. Der geheilte Test klickt das neue Element und läuft weiter. Die eigentliche Änderung im Ablauf fällt erst auf, wenn eine Assertion danach scheitert. Fehlt diese Assertion, fällt sie gar nicht auf.

Typische Folgen:

• Verdeckte Regressionen: Geänderte Labels, Feldtypen oder Abläufe rutschen ohne Review durch.
• Falsches Vertrauen: Das Dashboard zeigt grün, die Suite prüft aber nicht mehr das, was das Team glaubt.
• Schwache Assertions: Wer sich auf Heilung verlässt, schreibt seltener fachliche Prüfungen.
• Unklare Verantwortung: Ein Hinweis im Command Log ersetzt keinen Review im Merge Request.

Gleb Bahmutov, früher VP of Engineering bei Cypress, nennt Auto Healing deshalb ein Warnsignal für den Entwicklungsprozess. Wenn Tests ständig an Selektoren scheitern, liegt das Problem meist in der Teststruktur oder im fehlenden Abgleich zwischen Frontend und Tests.

Die meisten kaputten Selektoren hängen an Dingen, die sich ständig ändern: CSS Klassen, Tag Strukturen, generierte IDs. Die Cypress Best Practices empfehlen deshalb eigene data-cy Attribute. Sie sind von Styling und JavaScript Verhalten entkoppelt.

Ändert ein Designer die Klassen, bleibt der zweite Selektor stabil. Ändert sich das Verhalten, schlägt eine Assertion fehl, und das Team entscheidet bewusst. Genau das soll ein Test leisten.

Neben data-cy gibt es zwei weitere Bausteine, die Tests robust machen, ohne etwas zu verstecken.

Testing Library Queries: Cypress verweist in den Best Practices auf die Cypress Testing Library. Du suchst Elemente über Rolle und zugänglichen Namen, so wie Nutzer und Screenreader sie wahrnehmen. Ändert sich der Name eines Buttons, wird der Test rot. Das ist gewollt, denn Nutzer sehen die Änderung auch. Nebenbei prüfst du damit ein Stück Barrierefreiheit.

Custom Commands und Page Objects: Selektoren und Abläufe stehen an genau einer Stelle. Ändert sich das Login Formular, passt du einen Command an, und alle Tests laufen wieder. Das ist Wartung mit Review statt Heilung zur Laufzeit.

Mehr zu Barrierefreiheit in Tests findest du bei axe DevTools mit Cypress und in der Übersicht der Accessibility Testing Tools.

Der wichtigste Unterschied zwischen Heilung und Wartung ist der Review. Eine Änderung am Test landet im Merge Request, jemand liest sie und stimmt zu. So bleibt nachvollziehbar, warum ein Test anders prüft als vorher.

Wenn du cy.prompt mit Self Healing einsetzt, mach die Heilung sichtbar:

• Command Log lesen: Jeder Lauf mit Self Healed via Cache oder Self Healed via AI ist ein Hinweis auf eine UI Änderung.
• Code exportieren: Über den Code Button holst du den aktuellen Stand in die Testdatei und reviewst ihn wie normalen Code.
• Fachliche Assertions ergänzen: Prüfe Ergebnisse wie Weiterleitung, Text oder Datenzustand, nicht nur Sichtbarkeit.
• Kritische Pfade fest verdrahten: Login, Checkout und Rechteprüfungen laufen mit committetem Code ohne Self Healing.

Wie Anforderungen zum festen Maßstab für Tests werden, zeigt die lebende Spezifikation. Gemeinsame Beispiele dafür entstehen gut im Example Mapping.

KI Agenten können bei der Testwartung viel abnehmen. Der Unterschied zu Self Healing: Der Agent schlägt eine Änderung vor, ein Mensch reviewt und gibt frei. Nichts ändert sich still zur Laufzeit.

So sieht ein sauberer Ablauf aus:

• Fehler lesen: Der Agent holt sich fehlgeschlagene Runs, zum Beispiel über Cypress Cloud MCP.
• Ursache klären: Hat sich die UI gewollt geändert, oder ist es ein Bug?
• Änderung vorschlagen: Der Agent passt Selektor oder Custom Command an und öffnet einen Merge Request.
• Freigabe: Ein Mensch prüft den Diff und gibt frei. Testdateien sind geschützt, damit ein Agent rote Tests nicht passend umschreibt.
• Quality Gates: In CI laufen zuerst statische Analyse, Unit Tests und funktionale Tests, danach Cypress E2E.

Die Agenten arbeiten gegen lokale Entwicklungsumgebungen mit Faker Testdaten, nie gegen echte Kundendaten. Der Rahmen mit Scope, Evidenz und Freigabe steht im Governed Agent Loop.

Wenn Tests ständig an Selektoren scheitern, schauen wir zuerst auf die Ursache. Meist fehlen Test Attribute im Markup, Abläufe sind in jedem Test neu geschrieben, oder Frontend und Tests laufen getrennt. Das lösen wir mit data-cy Konventionen, Custom Commands und einem Review Prozess, der zum Team passt.

KI hilft uns dabei als Werkzeug, nicht als Schiedsrichter. Welche Regeln Agenten im Projekt bekommen, steht in einer AGENTS.md mit klaren Coding Regeln. Wie KI Code auf Dauer wartbar bleibt, zeigt Code Qualität mit KI Agenten. Die typischen Fallen fasst Vibe Coding Risiken zusammen. Wer vom Selenium Umfeld kommt, findet die Einordnung unter Selenium.

Passend dazu im NCA Cypress Glossar: Flaky Tests in Cypress, die oft hinter instabilen Selektoren stecken.

Kurze Antworten zu Self Healing in Cypress, zu den Risiken und zu stabilen Alternativen für deine Testsuite.