Was bedeutet KI Features testen mit Cypress?

KI Features testen mit Cypress heißt, Chatbots, KI Suche und Zusammenfassungen in deiner Anwendung Ende zu Ende abzusichern, obwohl das Modell nie zweimal dieselbe Antwort liefert. Du prüfst dabei die Integration: Request, Zustände im UI, Fehlerfälle und Grenzen, ohne dich auf den genauen Wortlaut zu verlassen.

Der Kern ist einfach. Mit cy.intercept ersetzt du die Antwort des Modells durch eine feste Fixture mit Testdaten. Damit wird der Test deterministisch. Gegen das echte Modell prüfst du nur Struktur, Schema und Grenzen, etwa Pflichtfelder, Längen und gültige Links.

Eine Sache gehört gleich an den Anfang: E2E Tests ersetzen keine Eval Pipeline. Cypress sagt dir, ob dein Feature technisch funktioniert. Ob die Antworten gut, richtig und sicher sind, messen Evals. Du brauchst beides.

Cypress mit Cypress Cloud läuft bei uns täglich in Production. Roland Golla ist offizieller Cypress Ambassador, arbeitet seit über 20 Jahren an Testing und Refactoring und hat Tests zum TYPO3 Core beigetragen. Automatisiert getestet wird bei NCA seit 2013. Auf der KI Seite nutzen wir OpenCode mit Open Weight Modellen über Ollama. Wir kennen also beide Seiten: das Feature, das ein Modell anspricht, und den Test, der es absichert.

Für Teams, die KI Features in ihr Produkt bringen, gibt es das Vibe Coding Consulting und als Rahmen die NCA Agentic AI Coding Guardrails. Hands on lernst du das Testen im Cypress Workshop mit Roland oder als ganzes Team in der Cypress Remote Schulung. Wie die Tests in der Pipeline greifen, zeigen die Quality Gates für KI Code. Für Entwicklerteams, die KI breiter einführen, gibt es die KI Weiterbildung für Entwicklerteams.

Ein klassischer E2E Test vergleicht Text. Klick auf Bestellen, erwarte „Danke für deine Bestellung“. Bei einem Chatbot klappt das nicht. Dieselbe Frage bringt heute drei Sätze und morgen fünf. Beide Antworten können richtig sein.

Wer trotzdem auf Wortlaut prüft, bekommt Flaky Tests. Der Test wird mal grün, mal rot, ohne dass sich am Code etwas geändert hat. Nach ein paar Wochen ignoriert das Team die roten Läufe. Ab da ist die Suite wertlos.

Die Lösung ist eine klare Trennung in drei Ebenen:

• Deterministische Tests mit gestubbter Modellantwort. Sie laufen bei jedem Merge Request, schnell und stabil.
• Wenige Smoke Tests gegen das echte Modell. Sie prüfen nur Struktur und Grenzen, etwa nachts oder vor einem Release.
• Evals außerhalb von Cypress. Sie bewerten die Qualität der Antworten.

Dazu passt eine Regel, die wir überall anwenden: Coding Modelle und Tests laufen gegen lokale Umgebungen mit Fake Daten, nie gegen echte Kundendaten. Wie du solche Daten erzeugst, steht im Beitrag zu Faker Testdaten für die lokale Entwicklung mit KI.

Mit cy.intercept fängst du den Request deiner App an dein Backend ab und lieferst eine feste Antwort aus einer Fixture. Wichtig: Du stubbst den Endpunkt deiner eigenen API. Der Browser spricht in der Regel nie direkt mit dem Modellanbieter, das übernimmt dein Server.

Lege pro Fall eine eigene Fixture an: eine normale Antwort, eine sehr lange, eine ohne Quellen, eine Ablehnung. So wird jeder Grenzfall zu einem stabilen Test.

Der Test prüft drei Dinge. Der Request geht mit der Nutzerfrage raus. Die Antwort erscheint im UI. Die Quellen stehen als Liste darunter. Alle Selektoren laufen über data-cy Attribute. Die bleiben stabil, auch wenn sich Klassen und Layout ändern.

Für den Smoke Test gegen das echte Modell nimmst du den Stub weg. cy.intercept bleibt als Spion ohne eigene Antwort. So wartest du auf den Request und prüfst die echte Antwort. Der Wortlaut bleibt dabei außen vor.

Diese Assertions halten, egal was das Modell formuliert:

• Status und Pflichtfelder: 200, answer ist ein String und nicht leer.
• Grenzen: Die Antwort bleibt unter einer Maximallänge, die dein UI verkraftet.
• Links: Quellen zeigen nur auf erlaubte Pfade deiner Anwendung.
• Sichtbarkeit: Die Antwort erscheint im UI und ist nicht leer.

Hat dein Backend ein festes Antwortschema, prüfst du genau das. Wie Schemas als Vertrag zwischen Modell und Code funktionieren, beschreibt der Beitrag zu Schema Based AI Coding. Halte diese Tests klein. Jeder Lauf kostet Token und Zeit, und das Ergebnis schwankt mit dem Modell.

Viele Chat Oberflächen zeigen die Antwort Stück für Stück. Technisch kommt sie oft als Server Sent Events. Hier lohnt sich ein ehrlicher Blick auf die Grenzen.

cy.intercept liefert einen Stub als Ganzes aus. Du kannst einen Body im Event Stream Format mitgeben. Dann testest du, ob deine App die Events richtig zusammensetzt und am Ende den richtigen Zustand zeigt. Das echte Tempo einzelner Chunks testest du damit nicht. Dazu kommt ein offenes GitHub Issue bei Cypress: Streams, die per fetch gelesen werden, kommen durch den Cypress Proxy teils gepuffert erst am Ende an.

Für das Verhalten während des Streams gilt: Prüfe Zustände. Ist der Stop Button sichtbar, solange gestreamt wird? Ist das Eingabefeld danach wieder frei? Wird nichts doppelt angezeigt? Wer Zwischenschritte genau prüfen will, baut in die App eine austauschbare Event Quelle ein und steuert sie im Test selbst.

Denk dabei an Barrierefreiheit. Ein Chat Verlauf braucht in der Regel eine Live Region, damit Screenreader neue Antworten ansagen. Das prüfst du mit einer Zeile: cy.get('[data-cy=chat-log]').should('have.attr', 'aria-live', 'polite'). Weitere Werkzeuge dafür findest du bei den Accessibility Testing Tools.

Modelle sind langsam, Anbieter drosseln, Netze brechen ab. Diese Fälle sieht man im Alltag selten, also testet sie kaum jemand. Mit cy.intercept erzeugst du jeden davon auf Knopfdruck.

• statusCode simuliert Rate Limits mit 429 oder Serverfehler mit 500.
• forceNetworkError trennt die Verbindung hart.
• delay macht die Antwort künstlich langsam. So prüfst du Ladeanzeige und den Schutz vor doppeltem Absenden.

Für echte Timeouts deiner App setzt du den Timeout Wert in der Testumgebung niedrig und gibst dem Stub ein delay knapp darüber. So bleibt der Test schnell und prüft trotzdem den Abbruch.

Guardrails sitzen meist im Backend. Ob sie greifen, siehst du aber im UI. Drei Fälle gehören in jede Suite.

Ablehnung. Das Modell verweigert eine Antwort. Die App zeigt eine klare Meldung und bietet keine Folgeaktion an, die auf einer echten Antwort aufbaut.

Ausgabe als Text. Modellausgabe ist Nutzereingabe aus zweiter Hand. Landet sie per innerHTML im DOM, ist das ein XSS Risiko. Ein Stub mit HTML im Antworttext deckt das auf.

Prompt Injection Eingaben. Ob dein Modell eine Injection abwehrt, prüft ein E2E Test nicht zuverlässig. Was er prüfen kann: Der Systemprompt kommt nie aus dem Browser. Schickt das Frontend ihn mit, kann jeder ihn ändern.

Mehr zu den Risiken von KI generiertem Code und KI Features steht in Vibe Coding Risiken und Gefahren.

Hier liegt das größte Missverständnis. Teams bauen eine saubere Cypress Suite für ihren Chatbot und glauben, die Qualität sei damit abgesichert. Ist sie nicht.

• Cypress E2E prüft die Integration: Request, Rendering, Zustände, Fehler, Guardrails im UI. Die Frage lautet: Funktioniert das Feature?
• Evals prüfen die Modellqualität: Sind die Antworten richtig, vollständig, im passenden Ton und ohne Halluzinationen? Die Frage lautet: Ist die Antwort gut?

Evals laufen auf Datensätzen mit vielen Beispielen, oft mit Bewertung durch ein zweites Modell oder durch Menschen. Dafür eignen sich Plattformen wie Langfuse, die Tracing, Evals und Prompt Management verbinden. Wechselt ein Prompt oder ein Modell, zeigen Evals, ob die Qualität hält. Cypress zeigt, ob das UI danach noch funktioniert.

Ehrlich gesagt: Eine E2E Suite ersetzt keine Eval Pipeline. Und eine Eval Pipeline ersetzt keine E2E Suite. Wer nur eines davon hat, sieht nur die halbe Wahrheit.

Wir beraten Teams, die KI Features in bestehende Anwendungen bringen. Das Muster ist oft gleich: Das Feature ist schnell gebaut, die Tests fehlen. Wir helfen dabei, zuerst die deterministische Ebene aufzubauen:

• Fixtures für Normalfall, Grenzfall und Fehler
• data-cy Selektoren auf allen Chat Elementen
• gestubbte Tests in jedem Merge Request

Danach kommen wenige Smoke Tests gegen das echte Modell und die Eval Ebene. Die Testergebnisse liest auch der Coding Agent, über Cypress Cloud MCP. Wer Akzeptanzkriterien vorher sauber formuliert, etwa mit Example Mapping, hat die Fixtures schon halb geschrieben. Wie Agenten gegen solche Kriterien prüfen, zeigen die agentischen Akzeptanztests. Für die Token Kosten der Smoke Tests ist ein Proxy wie LiteLLM mit Budget Limits geeignet.

Passend dazu im NCA Cypress Glossar: Cypress mit KI Agenten, cy.prompt für Tests in natürlicher Sprache und Cypress Test Replay für fehlgeschlagene Läufe im CI.

Die Fragen, die uns zum Testen von KI Features am häufigsten begegnen, kurz und direkt beantwortet.