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.

Wichtig vorab: E2E Tests und Evals haben verschiedene Aufgaben. Cypress sagt dir, ob dein Feature technisch funktioniert. Ob die Antworten gut, richtig und sicher sind, messen Evals. Du brauchst beides.

Wir bauen bei NCA selbst Features, die Modelle ansprechen. Im Alltag arbeiten wir mit OpenCode und Open Weight Modellen über Ollama. Dabei sehen wir laufend den Unterschied zwischen einem Feature, das läuft, und einer Antwort, die gut ist. Für das Feature haben wir Cypress, das bei uns mit Cypress Cloud täglich in Production läuft. Roland Golla ist offizieller Cypress Ambassador.

Teams, die KI Features in ihr Produkt bringen, begleiten wir in der Vibe Coding Beratung. Den Rahmen setzen die NCA Agentic AI Coding Guardrails. Gemeinsam mit dem Team legen wir fest, was Stubs, Smoke Tests und Evals abdecken, und hängen die Tests an die Quality Gates für KI Code in der Pipeline. Hands on lernst du das Testen im Cypress Workshop mit Roland Golla oder als ganzes Team in der Cypress Remote Schulung für Teams. Wer KI breiter im Team einführt, findet den Einstieg in der 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.

Alle drei Ebenen laufen gegen lokale Umgebungen mit Fake Daten, mehr dazu bei Testdaten in Cypress und 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.

Viele Teams bauen eine saubere Cypress Suite für ihren Chatbot und halten die Qualität damit für abgesichert. Die Suite deckt aber nur die Technik ab. Ob die Antworten gut sind, prüft sie nicht.

• Cypress E2E prüft die Integration: Request, Rendering, Zustände, Fehler, Guardrails im UI. Die Frage dahinter: Funktioniert das Feature?
• Evals prüfen die Modellqualität: Sind die Antworten richtig, vollständig, im passenden Ton und ohne Halluzinationen? Die Frage dahinter: 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.

Für ein KI Feature in Production brauchst du deshalb beide Ebenen: eine E2E Suite für die Integration und eine Eval Pipeline für die Qualität der Antworten.

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.

Im NCA Cypress Glossar geht es weiter mit Cypress mit KI Agenten, cy.prompt, Cypress Test Replay und Cypress AI Toolkit.

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