Cypress hat ein Beta-Feature namens tap veröffentlicht, das es KI-gesteuerten Coding-Agenten ermöglicht, sich an eine laufende Cypress-Testsitzung anzubinden, DOM-Snapshots und Command-Logs abzurufen und diese visuellen Informationen zur Diagnose von Fehlern zu nutzen. Das Tool funktioniert nur mit Cypress 15.21.0 oder neuer, einem Chromium-basierten Browser und der „cypress open“-UI; es läuft nicht im Headless-Modus.

Warum KI-Agenten mehr als nur einen Exit-Code benötigen

Die meisten KI-Coding-Assistenten behandeln einen Cypress-Lauf wie jedes andere Kommandozeilen-Tool: Sie führen npx cypress run aus, lesen den Exit-Status des Prozesses und entscheiden, ob der Test bestanden wurde. Ein Exit-Code teilt dem Agenten zwar mit, dass etwas schiefgelaufen ist, liefert aber keinen Hinweis darauf, ob ein Selektor falsch geschrieben wurde, eine Seite nicht geladen werden konnte oder ein Overlay einen Button blockierte. Menschen hingegen öffnen die Cypress-UI, beobachten den Browser, inspizieren den DOM-Baum und lesen das Command-Log, bevor sie eine Hypothese aufstellen.

Diese Lücke macht das automatisierte Debugging anfällig. „Element not found“ kann auf Dutzende von Ursachen zurückzuführen sein, und ohne visuelle Belege versucht eine KI möglicherweise immer wieder dieselbe Lösung, was in einer Endlosschleife endet.

Wie tap die Lücke schließt

Tap erstellt ein terminalbasiertes Interface zu einer laufenden Cypress-Instanz. Sobald der Entwickler Cypress im Open-Modus startet:

npx cypress open --e2e --browser=chrome

kann der Agent eine Reihe von Befehlen mit JSON-Ausgabe aus einer separaten Shell ausführen:

  • npx cypress tap specs --json – listet verfügbare Spec-Dateien auf.
  • npx cypress tap run <spec> --json – startet den Durchlauf einer einzelnen Spec.
  • npx cypress tap status --json – gibt den Status des aktuellen Durchlaufs zurück, einschließlich Zeitstempeln.

Da die Status-Payload einen startedAt-Zeitstempel enthält, kann der Agent verifizieren, dass er aktuelle Ergebnisse betrachtet und nicht einen veralteten Durchlauf, der bereits früher abgeschlossen wurde. Sich allein auf den rohen Exit-Code zu verlassen, reicht nicht mehr aus.

Wenn ein Test fehlschlägt, kann der Agent tiefer graben:

  • npx cypress tap reporter --json – ruft den gesamten Testbericht ab.
  • npx cypress tap command --test-id <ID> --command-id <ID> --json – ruft den exakten Befehl ab, der einen Fehler verursacht hat, zusammen mit einem Snapshot des App-DOMs, des ARIA-Baums und aller relevanten Elementattribute zu diesem Zeitpunkt.

Mit diesem Snapshot kann die KI analysieren, warum der Selektor nicht gegriffen hat, ob die Seite noch geladen wurde oder ob ein Modal das Ziel verdeckte. Sie kann dann eine Codeänderung vorschlagen, diese anwenden und dieselbe Spec erneut ausführen, um die Korrektur zu verifizieren.

Eine Sicherheitsrichtlinie für autonome Agenten

Um zu verhindern, dass die Schleife ewig läuft, schlägt das Cypress-Team einen disziplinierten Workflow vor:

  1. Führen Sie nur eine spezifische Spec-Datei aus.
  2. Überprüfen Sie tap status mit einer strikten Deadline und ignorieren Sie alle Ergebnisse, deren startedAt älter als die letzte Abfrage ist.
  3. Inspizieren Sie nur den fehlerhaften Test und den verursachenden Befehl.
  4. Erlauben Sie eine einzige Code-Modifikation vor dem nächsten Durchlauf.
  5. Führen Sie die Spec erneut aus.
  6. Wenn sich das Ergebnis ändert, stoppen Sie und benachrichtigen Sie einen Menschen zur Überprüfung.

Der Agent sollte zudem eine Erklärung in natürlicher Sprache generieren, was er beobachtet hat und warum die vorgeschlagene Lösung funktionieren sollte. Den Test zu bestehen, reicht nicht aus; die KI muss nachweisen, dass sie die visuellen Belege verstanden hat.

Wer davon profitiert

Entwickler, die bereits auf KI-Assistenten zur Codegenerierung setzen, können diesen Assistenten nun eine umfangreichere Debugging-Grundlage bieten. Der erwartete Nutzen liegt in einer Reduzierung der Zeit, die mit der Suche nach flaky Tests verbracht wird – insbesondere in großen End-to-End-Suites, in denen das manuelle Reproduzieren eines Fehlers Minuten dauern kann. Teams, die tap einsetzen, könnten schnellere Bearbeitungszeiten bei Pull Requests sehen, die UI-Komponenten betreffen, sowie einen geringeren Bedarf an zeitaufwendigen Debugging-Sessions.

Risiken und Einschränkungen

Tap befindet sich noch in der Beta-Phase, was bedeutet, dass es Fehler enthalten kann, die Befehlssyntax ändern oder die Unterstützung für bestimmte Konfigurationen ohne Vorankündigung einstellen kann. Die Abhängigkeit von der Open-UI schließt Headless-CI-Pipelines aus, sodass Teams eine separate Strategie für automatisierte Builds benötigen werden. Da das Feature Live-DOM-Daten streamt, entsteht ein geringer Performance-Overhead, der große Specs verlangsamen könnte. Schließlich setzt die Sicherheitsrichtlinie voraus, dass die KI Deadlines einhalten und nach einer einzigen Änderung stoppen kann; ein schlecht konzipierter Agent könnte dennoch in eine Endlosschleife geraten oder eine falsche Korrektur anwenden.

Worauf man als Nächstes achten sollte

  • Beta-Feedbackzyklen – Cypress wird das JSON-Schema wahrscheinlich verfeinern und basierend auf dem Input von Early Adoptern granularere Befehle hinzufügen.
  • Integration in die CI – Rechnen Sie mit Community-Skripten, die die Open-Mode-Anforderung von tap mit Headless-Runnern verbinden, etwa durch das Erstellen eines virtuellen Displays.
  • KI-Agent-Tooling – Anbieter, die Coding-Assistenten entwickeln, könnten damit beginnen, die tap-Unterstützung als Standard-Debugging-Modul zu bündeln, wodurch die Funktion in gängigen IDE-Erweiterungen sichtbarer wird.

Wenn Sie mit KI-gestützter Testwartung experimentieren, probieren Sie tap doch einmal an einem einzelnen flaky Spec aus und sehen Sie, ob der visuelle Kontext den Debugging-Zyklus verkürzt. Das Tool wird das menschliche Urteilsvermögen nicht ersetzen, aber es verleiht Ihrem Coding-Agenten ein Paar Augen, das ihm zuvor fehlte.