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.

Instabile Selektoren lösen wir dort, wo sie entstehen: im Markup und in der Teststruktur. Wenn bei uns ein Test an einem Selektor scheitert, schauen wir zuerst ins Template. Fehlt ein data-cy Attribut, hängt der Test an einer CSS Klasse, steht derselbe Ablauf in zehn Specs? Cypress mit Cypress Cloud läuft bei uns täglich in Production, in GitHub Actions und GitLab CI, in Projekten mit Symfony, Astro, React und Vue. Roland Golla ist offizieller Cypress Ambassador.

Mit deinem Team legen wir eine Selektor Strategie fest, die Redesigns übersteht, und bauen sie im Cypress Workshop mit Roland Golla oder in der Cypress Remote Schulung für Teams gemeinsam auf. Die Regeln dafür prüft das ESLint Plugin für Cypress automatisch. Wenn KI Agenten Tests pflegen sollen, setzen wir in der Vibe Coding Beratung 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.

Kurz gesagt: cy.prompt erzeugt aus natürlicher Sprache Cypress Code und speichert ihn im Cache. Passt ein Selektor nicht mehr, erzeugt Cypress den Schritt neu und markiert das im Command Log. Wie Cache und Heilung im Detail ablaufen, erklärt die Seite zu cy.prompt.

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. Dafür ist ein Test da.

Damit die Regel im Alltag hält, muss niemand Selektoren von Hand prüfen. Das ESLint Plugin für Cypress erzwingt mit der Regel require-data-selectors data Attribute automatisch und meldet jeden Selektor auf Klassen oder Tags.

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.

Welche weiteren Regeln für Testdateien, Pipeline und Daten bei uns gelten, steht auf der Seite Cypress mit KI Agenten. Den Rahmen mit Scope, Evidenz und Freigabe beschreibt der 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 nutzen wir dabei für Vorschläge und Routinearbeit. Ob eine Änderung am Test richtig ist, entscheidet ein Mensch im Review. Die Regeln für Agenten stehen in einer AGENTS.md mit klaren Coding Regeln, wie KI Code wartbar bleibt, zeigt Code Qualität mit KI Agenten, und 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.