Was ist cy.prompt?

cy.prompt ist ein Cypress Befehl, der Testschritte in natürlicher Sprache in ausführbare Cypress Befehle übersetzt. Du schreibst zum Beispiel „click the login button“, und Cypress sucht das passende Element, erzeugt den Code und führt ihn im Browser aus.

Cypress hat den Befehl auf der CypressConf 2025 vorgestellt. Eingeführt wurde er mit Version 15.4.0 als experimentelles Feature. Seit Version 15.13.0 ist cy.prompt im Beta Status, das Config Flag experimentalPromptCommand ist entfallen. Du brauchst einen Cypress Cloud Account oder einen gültigen Record Key. cy.prompt läuft nur in E2E Tests und nur in Chromium Browsern wie Chrome und Edge.

Für Teams ohne Testsuite ist das ein guter Weg, mit dem Testen anzufangen und nach vorne zu gehen. Ein Test in natürlicher Sprache ersetzt aber keine Teststrategie. Welche Fälle fehlen, welche Assertion etwas absichert und wo ein Test brüchig wird, entscheidet weiter ein Mensch mit Testing Erfahrung.

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 läuft bei uns täglich in Production. cy.prompt ordnen wir als Einstieg ein: Es bringt Teams schnell zu ersten Tests. Unsere Testing Arbeit geht weit darüber hinaus, von der Teststrategie über stabile Selektoren bis zu Quality Gates für KI Code in der Pipeline.

Im Cypress.IO Workshop bauen wir mit dir die ersten Tests und zeigen, wie du generierte Schritte prüfst. Für ganze Teams gibt es die Cypress.IO Remote Schulung. Wenn KI Agenten Tests schreiben sollen, hilft unser Vibe Coding Consulting mit klaren Regeln aus den NCA Agentic AI Coding Guardrails. Wie Agenten Testergebnisse lesen, zeigt Cypress Cloud MCP.

Du übergibst cy.prompt ein Array mit Schritten. Jeder Eintrag ist ein Satz. Laut Cypress Doku passiert dann Folgendes:

• Prompt verstehen: Ein KI Modell liest jeden Schritt.
• Selektor wählen: Cypress prüft das DOM deiner App und wählt einen Selektor nach festen Prioritätsregeln.
• Code erzeugen: Daraus entstehen echte Befehle wie cy.get, cy.click oder cy.type, die nacheinander laufen.
• Cache nutzen: Der erzeugte Code landet im Cache und wird zwischen Maschinen und in CI geteilt.
• Selbst heilen: Passt ein gecachter Selektor nicht mehr, erzeugt Cypress den Schritt neu.

Ein einfacher Login Test nach dem Muster der Cypress Doku sieht so aus:

Die Schritte sind auf Englisch geschrieben. Cypress optimiert cy.prompt für englische Prompts, andere Sprachen sind nicht garantiert. Das Passwort läuft über placeholders. Platzhalter Werte schickt Cypress nie an das KI Modell, und sie halten den Cache stabil. Passwortfelder, Kreditkartenfelder und versteckte Inputs blendet Cypress laut Doku automatisch aus, bevor DOM Daten an das Modell gehen.

cy.prompt spielt seine Stärke dort aus, wo noch gar keine Tests existieren. Du beschreibst eine User Journey, und nach wenigen Minuten läuft ein erster Test im Browser. Das senkt die Hürde für Teams, die bisher nur manuell klicken.

Gute Einsatzfälle:

• Erste Smoke Tests für Login, Suche oder Checkout, damit die wichtigsten Wege abgesichert sind.
• Akzeptanzkriterien greifbar machen: Product Owner und QA formulieren Schritte, Entwickler prüfen den erzeugten Code.
• Gherkin Szenarien im Given, When, Then Stil, die du direkt als Schritte übergibst.
• Prototypen und Spikes, bei denen du schnell sehen willst, ob ein Flow technisch durchläuft.

Weniger passend ist cy.prompt für fachlich tiefe Prüfungen. Grenzwerte, Fehlerpfade, Rechteprüfungen und Datenzustände brauchen jemanden, der weiß, was getestet werden muss. Das Werkzeug schreibt Schritte. Die Frage, welche Schritte fehlen, beantwortet es nicht. Wie Akzeptanzkriterien dafür sauber entstehen, zeigt Example Mapping.

Cypress beschreibt in der Doku zwei Arbeitsweisen. Beim ersten Weg generierst du den Test, exportierst den Code und committest ihn. Dann weißt du genau, welcher Code bei jedem Lauf ausgeführt wird, und der Test braucht keinen KI Dienst mehr.

Beim zweiten Weg bleibt cy.prompt im Test. Ändert sich ein Element, heilt Cypress den Schritt selbst, entweder über den Cache oder über einen neuen KI Aufruf. Im Command Log steht dann Self Healed via Cache oder Self Healed via AI. Was Self Healing Tests grundsätzlich leisten und wo sie an Grenzen stoßen, erklärt eine eigene Glossarseite. Was das für die Aussagekraft deiner Tests bedeutet, schauen wir uns in der Tabelle an.

Neben jedem cy.prompt Aufruf zeigt das Command Log einen Code Button, auch bei fehlgeschlagenen Tests. Dahinter steht der komplette erzeugte Code mit Kommentaren, welcher Schritt welchen Befehl ausgelöst hat. Du kannst den Code in die Testdatei speichern und damit den cy.prompt Aufruf ersetzen oder ihn kopieren.

Lies diesen Code wie jeden anderen Code im Review. Diese Fragen helfen:

• Selektoren: Greift der Test auf data-cy Attribute zu oder auf CSS Klassen, die sich beim nächsten Redesign ändern?
• Assertions: Prüft der Test ein fachliches Ergebnis oder nur, dass irgendein Element sichtbar ist?
• Testdaten: Laufen die Schritte gegen Fake Daten aus einer lokalen Umgebung?
• Lesbarkeit: Versteht ein Kollege in drei Monaten, was der Test absichert?

Ein überarbeiteter Test nach dem Export kann so aussehen:

Der Test prüft jetzt die Weiterleitung und einen konkreten Text. Die Selektoren hängen an data-cy Attributen, die Cypress selbst in den Best Practices empfiehlt. Testdaten kommen aus Faker Testdaten für die lokale Entwicklung, nie aus echten Kundendaten.

Die offizielle Doku nennt klare Grenzen. Du solltest sie kennen, bevor du eine Suite darauf aufbaust:

• Nur E2E: Component Tests werden nicht unterstützt.
• Nur Chromium: Chrome und Edge, kein Firefox, kein WebKit.
• Nicht alle Cypress APIs: cy.request, Cookies und Sessions löschen oder zu Elementen scrollen gehen nicht per Prompt.
• Canvas und iframes: Diese Elemente werden nicht unterstützt.
• Assertions: „not.exist“ aus natürlicher Sprache klappt nicht, Assertions auf mehrere Elemente ebenfalls nicht.
• Sprache: Optimiert für Englisch, andere Sprachen sind nicht garantiert.

Dazu kommen organisatorische Punkte. Cypress Cloud zählt cy.prompt Ausführungen auf Ebene der Organisation, für Läufe ohne Recording gibt es Limits pro Nutzer und Stunde. Die aktuellen Konditionen stehen in der Cypress FAQ zu cy.prompt. Cypress Cloud ist ein US Anbieter. Laut Cypress werden Prompts nicht zum Training von KI Modellen genutzt, und sensible Felder werden ausgeblendet. Trotzdem gehören DOM Inhalte deiner App an einen externen Dienst. Kläre das mit deinem Datenschutz, bevor Tests gegen Umgebungen mit echten Daten laufen.

Organisationsadmins können die KI Funktionen in den Cypress Cloud Einstellungen abschalten. Für Teams mit strengen Vorgaben ist das ein wichtiger Hebel. Mehr zu den Risiken von KI im Entwicklungsprozess findest du unter Vibe Coding Risiken.

cy.prompt ist ein Startpunkt. Der Weg nach vorne führt zu Tests, die du verstehst, versionierst und im Team reviewst. So sieht der Übergang in der Praxis aus:

• Generieren: Schritte in natürlicher Sprache formulieren und laufen lassen.
• Exportieren: Den erzeugten Code über den Code Button in die Testdatei übernehmen.
• Härten: data-cy Selektoren setzen, fachliche Assertions ergänzen, wiederkehrende Abläufe in Custom Commands auslagern.
• Absichern: Den Test als Quality Gate in GitHub Actions oder GitLab CI laufen lassen.

Wenn KI Agenten bei Cypress Tests mitarbeiten, gilt dieselbe Reihenfolge. Der Agent schreibt den Test, ein Mensch reviewt und gibt frei. Testdateien sind geschützt, damit ein Agent einen roten Test nicht einfach umschreibt. In CI laufen zuerst statische Analyse, Unit Tests und funktionale Tests, danach Cypress E2E. Die Regeln dafür hältst du in einer AGENTS.md mit klaren Coding Regeln fest.

Wie cy.prompt in Akzeptanztests passt, bei denen ein Agent gegen Anforderungen arbeitet, beschreiben wir ausführlich bei den agentischen Akzeptanztests. Aus Tests, die dauerhaft gepflegt werden, entsteht mit der Zeit eine lebende Spezifikation.

Wir sehen cy.prompt als guten ersten Schritt. Teams ohne Tests kommen damit in Bewegung, und das ist viel wert. Für Suiten, die über Jahre tragen, braucht es mehr: eine Teststrategie, stabile Selektoren, saubere Testdaten und Reviews. Genau dabei helfen wir Teams, als Cypress Ambassador und mit über 20 Jahren Erfahrung in Testing und Refactoring.

In KI gestützten Workflows verbinden wir Cypress mit klaren Leitplanken. Wie ein Agent mit Scope, Evidenz und Freigabe arbeitet, beschreibt der Governed Agent Loop. Was KI Code im Alltag an Qualität braucht, steht bei Code Qualität mit KI Agenten. Wer vom Selenium Umfeld kommt, findet die Einordnung im Glossar unter Selenium. Für ganze Entwicklerteams gibt es die KI Weiterbildung für Entwicklerteams.

Passend dazu im NCA Cypress Glossar: Flaky Tests in Cypress, die bei generierten Tests schnell entstehen.

Hier findest du kurze Antworten zu Voraussetzungen, Self Healing, Datenschutz und dem Weg von cy.prompt zu klassischen Cypress Tests.