NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Testblöcke vom KI Agenten, Entwicklerin gibt mit Stempel frei

Was bedeutet Cypress mit KI Agenten?

Cypress mit KI Agenten heißt, dass ein Coding Agent Cypress Tests schreibt, ausführt und wartet, während ein Mensch jeden Test prüft und freigibt. Der Agent übernimmt Tipparbeit und Fehlersuche, die Verantwortung für die Qualität bleibt beim Team.

Damit das trägt, braucht der Agent klare Leitplanken: Regeln in einer AGENTS.md, stabile data-cy Selektoren, geschützte Testdateien, ein Review vor jedem Merge und Quality Gates in der CI. Ergebnisse roter Läufe liest er über Cypress Cloud MCP selbst aus.

Das Risiko liegt auf der Hand. Ein Agent, der Code und Tests zugleich ändern darf, kann einen roten Test einfach grün machen. Dann prüft der Test nichts mehr. Genau darum geht es auf dieser Seite: Tests schreiben lassen und trotzdem Qualität behalten.

Inhalt

Cypress und KI Agenten mit NCA: Schnelle Hilfe vom Experten

Bei uns läuft Cypress mit Cypress Cloud täglich in Production. Unser Coding Agent ist OpenCode mit Open Weight Modellen, lokal über Ollama und über Ollama Cloud. Roland Golla ist offizieller Cypress Ambassador, arbeitet seit über 20 Jahren an Testing und Refactoring und hat Tests zum TYPO3 Core beigetragen. Automatisiertes Testen gehört bei NCA seit 2013 zum Alltag. Wir kennen also die Tests und den Agenten, der sie schreibt.

Wie Agenten im Team sauber arbeiten, klären wir im Vibe Coding Consulting und mit den NCA Agentic AI Coding Guardrails. Wie OpenCode sich konfigurieren lässt, steht bei den OpenCode Features und Plugins. Das Testen selbst lernst du im Cypress Workshop mit Roland oder als Team in der Cypress Remote Schulung. Für den breiten Einstieg in KI-gestützte Entwicklung gibt es die KI Weiterbildung für Entwicklerteams.

NCA Cypress Workshop mit Cypress Ambassador Roland Golla

E2E Tests, die euer Team selbst schreibt

Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.

  1. 1
    Kostenloses Vorgespräch
    Projekt, Stack und Teststand klären
  2. 2
    Workshoptag bei euch
    Setup, Patterns und erste Tests im Team
  3. 3
    Praxistag optional
    Tests im eigenen Projekt und in CI
Roland Golla
Roland Golla
Fullstack Developer
Zum Cypress Workshop arrow_forward

Was Agenten bei Cypress Tests gut können und wo sie scheitern

Coding Agenten sind bei Cypress erstaunlich produktiv. Die API ist gut dokumentiert, die Muster wiederholen sich, und ein Test lässt sich sofort ausführen. Das ergibt einen kurzen Loop: schreiben, laufen lassen, Fehler lesen, nachbessern.

Gut funktioniert:

  • neue Specs zu klar beschriebenen Anforderungen
  • Fixtures und Stubs für cy.intercept
  • Custom Commands und Page Objects nach vorhandenem Muster
  • eine erste Analyse roter Läufe

Schwach sind Agenten dort, wo Wissen fehlt, das nicht im Code steht. Welche Fälle fachlich wichtig sind, weiß der Agent nicht. Er testet, was er sieht. Er greift zu fragilen Selektoren, wenn keine stabilen da sind. Und er neigt dazu, einen Test an den Code anzupassen, obwohl der Code falsch ist.

Deshalb gilt bei uns eine einfache Reihenfolge: Der Agent schreibt, der Mensch reviewt und gibt frei. Davor laufen Quality Gates in der CI: statische Analyse, Unit Tests, funktionale Tests und Cypress E2E. Die Modelle arbeiten gegen lokale Entwicklungsumgebungen mit Fake Daten. Wie das als Prozess aussieht, beschreiben die Quality Gates für KI Code.

Kontext geben: AGENTS.md, Rules und Cypress AI Skills

Ein Agent kennt deine Konventionen nicht, solange du sie nicht aufschreibst. OpenCode liest dafür eine AGENTS.md im Projektwurzelverzeichnis. Andere Agenten nutzen eigene Dateien oder Rules mit ähnlichem Zweck. Was hineingehört, ist kurz und konkret.

Code: 
          
## Cypress Tests

- Specs liegen in cypress/e2e, eine Datei pro Feature.
- Selektoren nur über data-cy. Fehlt eins, ergänze es im App Code.
- Keine festen Wartezeiten mit cy.wait(Zahl). Warte auf Aliase oder Assertions.
- Netzwerk mit cy.intercept stubben, Fixtures in cypress/fixtures.
- Bestehende Specs nie ändern, um einen roten Test grün zu machen.
  Melde den Fehler und beschreibe die Ursache.
- Cypress immer mit --reporter=dot -q ausführen.

Die letzte Regel stammt aus einem Beitrag im Cypress Blog. Mit dem Dot Reporter und dem Quiet Flag schrumpft die Testausgabe im Kontext des Agenten deutlich. Die Fehlerzusammenfassung mit Stack Trace bleibt erhalten. Das spart bei jedem weiteren Schritt Token.

Cypress bietet außerdem eigene AI Skills an. Das sind fünf Skills, unter anderem zum Schreiben, Erklären und Debuggen von Tests. Sie bevorzugen dedizierte Test Attribute wie data-cy und schlagen vor, eins im App Code zu ergänzen, wenn kein stabiler Selektor existiert.

Code: 
          
npx skills add cypress-io/ai-toolkit

Wie du Regeldateien sauber strukturierst, steht im Beitrag zu Rules.md und AGENTS.md.

data-cy Selektoren als Konvention

Selektoren sind die häufigste Schwachstelle in Tests, die ein Agent schreibt. Ohne Vorgabe nimmt er, was er findet: Klassen aus Tailwind, verschachtelte CSS Pfade, sichtbare Texte. Beim nächsten Redesign bricht alles.

Code: 
          
<button class="btn btn-primary mt-4" data-cy="checkout-submit">
  Jetzt bestellen
</button>
Code: 
          
// fragil: hängt an Styling
cy.get('.btn.btn-primary.mt-4').click()

// stabil: eigenes Test Attribut
cy.get('[data-cy=checkout-submit]').click()

Die Regel ist einfach: Der Agent darf data-cy Attribute im App Code ergänzen, aber Tests nie auf Klassen stützen. Das lässt sich im Review in Sekunden prüfen. Text Selektoren mit cy.contains sind nur dann sinnvoll, wenn eine Textänderung den Test bewusst brechen soll. In unseren Astro, React und Vue Projekten setzen wir data-cy direkt in den Komponenten.

Testdateien schützen

Das größte Risiko beim Testen mit Agenten: Der Agent ändert den Test, wo er den Code ändern müsste. Der Lauf wird grün, der Fehler bleibt. Das passiert ohne böse Absicht. Der Agent optimiert auf grün.

In OpenCode setzt du dafür Berechtigungen pro Pfad. Die Edit Berechtigung deckt alle Dateiänderungen ab, also Bearbeiten, Schreiben und Patches. Bei mehreren passenden Regeln gewinnt die letzte. Darum steht der Platzhalter für alle Dateien vorne.

Code: 
          
{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": {
      "*": "allow",
      "cypress/e2e/**": "ask",
      "cypress/fixtures/**": "ask",
      "cypress.config.*": "deny"
    }
  }
}

Mit ask fragt der Agent vor jeder Änderung an Specs und Fixtures nach. Du siehst den Diff und entscheidest. Die Cypress Konfiguration bleibt mit deny ganz gesperrt. Dazu kommt eine zweite Sicherung im Repository: Änderungen an Testdateien brauchen im Merge Request ein eigenes Review, etwa über eine CODEOWNERS Datei in GitHub oder GitLab.

Dasselbe Muster beschreiben die agentischen Akzeptanztests: Der Agent testet gegen Kriterien, die er selbst nicht ändern darf.

Agent im Loop: Ergebnisse über Cypress Cloud MCP lesen

Ein Agent, der Tests schreibt, muss auch sehen, was in der CI passiert. Ohne Anbindung kopierst du Stack Traces in den Chat. Mit Cypress Cloud MCP holt sich der Agent Runs, fehlgeschlagene Tests, Flaky Tests und Test Replay Links selbst. Der Zugang ist rein lesend.

Für die Failure Triage hat sich ein fester Ablauf bewährt:

  • Einordnen: Ist der Fehler echt, flaky oder ein Problem der Umgebung?
  • Belegen: Stack Trace, Test Replay und betroffenen Code zusammen lesen.
  • Vorschlagen: Fix im App Code oder eine begründete Änderung am Test, nie beides stillschweigend.
  • Freigeben: Der Mensch entscheidet, die Pipeline bestätigt.

Ein Prompt, der diesen Ablauf vorgibt, kann so aussehen:

Code: 
          
Hol dir aus Cypress Cloud den letzten Run auf diesem Branch.
Ordne jeden Fehlschlag ein: echter Fehler, flaky oder Umgebung.
Lies Stack Trace und betroffenen Code.
Schlag einen Fix im App Code vor. Ändere keine Specs.
Wenn du glaubst, der Test ist falsch, begründe es und frag nach.

Wie solche Schleifen planbar bleiben, beschreibt der Governed Agent Loop mit Scope, Evidenz und Freigabe. Den Merge Request selbst kann der Agent über den GitHub MCP Server oder die GitLab CLI als MCP Server vorbereiten. Gemergt wird nach dem Review.

Vier Level: Vom manuellen Test zum Agenten im Loop

Teams gehen selten in einem Schritt vom manuellen Test zum Agenten im Loop. Die vier Level zeigen, was sich jeweils ändert und welche Absicherung dazugehört. Jedes Level baut auf dem vorherigen auf. Ein Level zu überspringen rächt sich meist beim ersten großen Refactoring.

Cypress mit KI Agenten: vier Level

Level Was der Agent tut Absicherung
1 Manuell Nichts. Du schreibst die Tests selbst, KI hilft höchstens beim Nachschlagen. Code Review im Team, Cypress in der CI
2 Assistiert Schlägt Selektoren, Fixtures und einzelne Tests vor. Du übernimmst und passt an. Regeln in der AGENTS.md, data-cy Konvention
3 Agent schreibt Schreibt neue Specs zu einer Anforderung und führt sie lokal aus. Geschützte Testdateien, Quality Gates in der CI, Review vor dem Merge
4 Agent wartet im Loop Liest rote Runs über Cloud MCP, ordnet ein und schlägt Fixes vor. Edit Rechte auf ask, Token Budget, Freigabe durch einen Menschen

Kosten, Token und Grenzen

Agenten kosten Token, und Testausgaben sind teuer. Jede Zeile, die Cypress ausgibt, landet im Kontext und reist bei jedem weiteren Schritt mit. Drei Hebel helfen:

  • Kurze Ausgabe: Cypress mit --reporter=dot -q starten.
  • Gezielte Läufe: lokal nur die betroffene Spec mit --spec ausführen. Die ganze Suite läuft in der CI.
  • Budgets: Ein Proxy wie LiteLLM zeigt den Verbrauch pro Nutzer und Team und setzt harte Limits.
Code: 
          
npx cypress run --spec cypress/e2e/checkout.cy.js --reporter=dot -q

Mit Open Weight Modellen lokal über Ollama fallen keine Token Kosten bei einem Anbieter an. Dafür brauchst du passende Hardware, und kleinere Modelle machen bei langen Specs mehr Fehler. Welche Modelle mit Tool Calling gut umgehen, zeigt der Vergleich der besten KI Modelle für MCP und Tool Handling.

Die Grenzen bleiben. Ein Agent erfindet keine fachlichen Testfälle, die niemand beschrieben hat. Er erkennt nicht, ob ein Test die richtige Frage stellt. Und er trägt keine Verantwortung für das Release. Gute Tests entstehen aus Anforderungen, etwa per Example Mapping, und aus Erfahrung mit dem System.

Und cy.prompt? Mit dem Befehl schreibst du Testschritte in natürlicher Sprache, Cypress setzt sie in Code um. Das ist ein guter Weg, mit dem Testen anzufangen und schnell nach vorne zu kommen. Für eine belastbare Suite brauchst du trotzdem das Handwerk dahinter: saubere Selektoren, Stubs, Fixtures und Tests, die fachlich das Richtige prüfen.

You don't have a testing problem. You have a trust problem.

Vladimir Mikhalev, Docker Captain und Cypress Ambassador – DEV Community: Cypress in the Age of AI Agents

Aus der NCA Praxis: Agenten schreiben, Menschen geben frei

Wir helfen Teams, Agenten in bestehende Cypress Suiten zu holen, ohne Qualität zu verlieren. Der Einstieg folgt fast immer derselben Reihenfolge:

  • Konventionen in der AGENTS.md aufschreiben
  • data-cy Attribute nachrüsten
  • Testdateien schützen und Review Pflicht einführen
  • erst dann neue Specs vom Agenten schreiben lassen

Für die fachliche Grundlage arbeiten wir mit einer lebenden Spezifikation und der Dokumentenkette aus ADR, PRD und BDD. So bekommt der Agent Anforderungen und muss nichts vermuten. Testdaten erzeugt er lokal mit Faker Testdaten, nie aus echten Kundendaten. Wie Agenten insgesamt sauberen Code liefern, beschreibt der Beitrag zur Code Qualität mit KI Agenten.

Passend dazu im NCA Cypress Glossar: cy.prompt für Tests in natürlicher Sprache, Flaky Tests in Cypress für die Triage roter Läufe und Cypress Test Replay als Beleg für den Agenten.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Cypress mit KI Agenten

Die Fragen, die uns zu Agenten und Cypress Tests am häufigsten begegnen, kurz und direkt beantwortet.

Können KI Agenten 2026 Cypress Tests schreiben?

Ja, und oft gut. Coding Agenten schreiben Specs, Fixtures und Stubs schnell, weil die Cypress API gut dokumentiert ist und sich Tests sofort ausführen lassen. Schwach sind sie bei fachlichen Fällen, die nicht im Code stehen, und bei Selektoren ohne Konvention. Deshalb gilt: Der Agent schreibt, ein Mensch reviewt und gibt frei.

Welcher Coding Agent passt 2026 zu Cypress?

Jeder Agent, der Dateien bearbeiten, Befehle ausführen und MCP Server nutzen kann. Wir setzen OpenCode mit Open Weight Modellen ein, lokal über Ollama oder über Ollama Cloud. Claude Code, Cursor und GitHub Copilot sind ebenfalls geeignet und werden in der Cypress Doku genannt. Wichtiger als das Werkzeug sind Regeln, Berechtigungen und Review.

Was gehört 2026 in die AGENTS.md für Cypress?

Kurze, prüfbare Regeln. Wo Specs liegen, dass Selektoren nur über data-cy laufen, dass feste Wartezeiten tabu sind und Netzwerk per cy.intercept gestubbt wird. Dazu die wichtigste Regel: bestehende Specs nie ändern, um einen roten Test grün zu machen. Und der Hinweis, Cypress mit --reporter=dot -q auszuführen, um Token zu sparen.

Wie schütze ich 2026 Testdateien vor dem Agenten?

Über Berechtigungen im Agenten und Regeln im Repository. In OpenCode setzt du die Edit Berechtigung für cypress/e2e auf ask, dann fragt der Agent vor jeder Änderung nach. Die Cypress Konfiguration sperrst du mit deny. Im Repository sorgt eine CODEOWNERS Datei dafür, dass Änderungen an Tests ein eigenes Review brauchen.

Was bringt Cypress Cloud MCP 2026 für Agenten?

Der Agent liest Testergebnisse selbst. Er holt Runs, fehlgeschlagene Tests mit Stack Trace, Flaky Tests und Test Replay Links direkt aus Cypress Cloud. Du musst nichts mehr in den Chat kopieren. Der Zugriff ist rein lesend und an deine Rechte in der Organisation gebunden. Cypress Cloud ist ein US Anbieter, das gehört bei Datenschutzfragen auf den Tisch.

Warum data-cy Attribute und keine CSS Klassen?

Weil data-cy nur für Tests da ist und sich beim Redesign nicht ändert. Klassen hängen am Styling, gerade mit Tailwind ändern sie sich ständig. Agenten greifen ohne Vorgabe zu dem, was sie finden. Eine klare Konvention verhindert das. Die Cypress AI Skills bevorzugen ebenfalls dedizierte Test Attribute und schlagen vor, fehlende im App Code zu ergänzen.

Darf der Agent einen roten Test selbst reparieren?

Er darf einen Vorschlag machen, aber nicht still ändern. Ein roter Test zeigt oft einen echten Fehler im Code. Passt der Agent den Test an, ist der Fehler versteckt. Deshalb trennt er in der Triage zwischen echtem Fehler, Flaky Test und Umgebungsproblem und begründet jede Änderung an einer Spec. Die Freigabe bleibt beim Menschen.

Wie halte ich die Token Kosten im Griff?

Mit kurzer Testausgabe, gezielten Läufen und Budgets. Cypress mit --reporter=dot -q verkleinert die Ausgabe im Kontext deutlich. Mit --spec läuft lokal nur die betroffene Datei, die volle Suite bleibt in der CI. Ein Proxy wie LiteLLM zeigt den Verbrauch pro Nutzer und setzt harte Limits. Lokale Modelle über Ollama sparen Anbieterkosten, brauchen aber Hardware.

Was sind die Cypress AI Skills?

Ein offizielles Paket von Cypress, das Coding Agenten beibringt, Tests wie erfahrene Cypress Engineers zu schreiben. Es gibt fünf Skills, unter anderem zum Schreiben, Erklären und Debuggen von Tests, zum Auslesen von Cloud Runs und zur Doku. Installiert wird es mit npx skills add cypress-io/ai-toolkit. Es läuft mit Agenten, die Skills oder eigene Anweisungen unterstützen.

Ist cy.prompt eine Alternative zu Coding Agenten?

Es ist ein anderer Ansatz. Mit cy.prompt schreibst du Testschritte in natürlicher Sprache, Cypress macht daraus Code. Das ist ein guter Weg, mit dem Testen anzufangen und schnell nach vorne zu kommen. Coding Agenten arbeiten breiter: Sie schreiben Specs, Fixtures und App Code. Für eine belastbare Suite brauchst du in beiden Fällen Review und saubere Konventionen.

Ersetzt ein Agent die Quality Engineers im Team?

Nein. Der Agent übernimmt Tipparbeit, erste Analysen und Routinefälle. Welche Fälle fachlich zählen, welche Risiken ein Release hat und ob ein Test die richtige Frage stellt, entscheiden Menschen. Quality Engineers verschieben ihren Fokus: weniger Tests tippen, mehr Regeln, Reviews und Teststrategie. Genau das macht den Agenten erst nützlich.

Gegen welche Umgebung soll der Agent Tests ausführen?

Gegen eine lokale Entwicklungsumgebung mit Fake Daten. Echte Kundendaten haben im Kontext eines Agenten nichts zu suchen. Testdaten erzeugst du reproduzierbar, etwa mit Faker, und externe Dienste stubbst du per cy.intercept. Die volle Suite läuft danach in der CI, am besten gegen eine Staging Umgebung mit denselben Fake Daten.