Was ist Cypress UI Coverage?

Cypress UI Coverage ist eine Funktion in Cypress Cloud, die zeigt, welche interaktiven Elemente deiner Anwendung deine Tests anfassen und welche nicht. Gemeint sind Buttons, Eingabefelder, Links und andere Bedienelemente, gemessen pro Seite oder Zustand deiner App.

Du musst dafür nichts installieren und keinen Code instrumentieren. Der Report entsteht in Cypress Cloud aus den Test Replay Daten, die deine aufgezeichneten Runs ohnehin erfassen. Cypress sucht in den DOM Snapshots jedes interaktive Element und prüft, ob ein bekannter Cypress Befehl wie click, type oder check damit gearbeitet hat.

Das Ergebnis ist eine Karte deiner Lücken. Du siehst einen Coverage Score, die riskantesten Views, jedes ungetestete Element mit einem inspizierbaren Snapshot und Links auf Seiten, die deine Suite nie besucht. Damit beantwortest du eine Frage, die Code Coverage nicht beantwortet: Welche Teile der Oberfläche hat noch kein Test benutzt?

Cypress mit Cypress Cloud läuft bei uns täglich in Production. Roland Golla ist offizieller Cypress Ambassador, testet seit über zwanzig Jahren und baut bei NCA seit 2013 automatisierte Tests. Wir wissen deshalb, wie eine Suite aussieht, die grün ist und trotzdem halbe Formulare ungeprüft lässt. Genau diese Lücke macht UI Coverage sichtbar, und genau dort setzen wir an: bei Selektoren, Testabdeckung und Regeln, die ein Team selbst tragen kann.

Passend dazu: der Cypress Workshop mit Roland Golla für Teams, die ihre Suite strukturiert aufbauen, die Cypress Remote Schulung für Teams, die Vibe Coding Beratung für KI Agenten im Entwicklungsalltag, unser Artikel zu Quality Gates für KI Code und der Leitfaden zu Accessibility Testing mit axe DevTools und Cypress.

Der Ablauf ist kurz. Du nimmst einen Run mit cypress run --record in Cypress Cloud auf, Test Replay ist aktiv. Nach dem Run analysiert Cypress Cloud die DOM Snapshots, findet die interaktiven Elemente und gleicht sie mit den Befehlen deiner Tests ab. Weil das erst nach der Aufzeichnung passiert, wartet deine Pipeline nicht darauf und scheitert auch nicht daran.

Der Report besteht aus vier Bausteinen:

• Views: Seiten oder Zustände deiner App. Jede View bekommt einen eigenen Score. So sortierst du nach Risiko statt nach Bauchgefühl.
• Interaktive Elemente: Buttons, Inputs, Links und Controls. Jedes ungetestete Element siehst du in einem Snapshot der ganzen Seite.
• Ungetestete Links: Seiten, auf die deine App verlinkt, die aber kein Test besucht. Hier fehlen oft ganze Flows.
• Coverage Score: getestete Elemente geteilt durch alle Elemente.

Laut Doku brauchst du drei Dinge: ein Projekt, das in Cypress Cloud aufzeichnet, aktiviertes Test Replay und Cypress ab Version 13. UI Coverage funktioniert für E2E Tests und für Component Tests. Im Component Testing wird jede Spec Datei zu einer eigenen View.

UI Coverage erkennt interaktive Elemente auf drei Wegen. Erstens über Tags wie a, button, input, select und textarea. Zweitens über explizite Rollen wie role button, checkbox oder tab. Drittens über alles, was per Tastatur erreichbar ist, also tabindex ab 0. Eigene Elemente markierst du mit dem Attribut data-cy-ui-interactive auf include.

Als getestet zählt ein Element nur, wenn ein Interaktionsbefehl es berührt hat. Die Standardliste der Doku: blur, check, clear, click, dblclick, focus, rightclick, scrollIntoView, scrollTo, select, selectFile, submit, trigger, type und uncheck.

Zwei Punkte überraschen viele Teams:

• Assertions zählen standardmäßig nicht. Ein cy.get mit should be.visible macht ein Element nicht zu einem getesteten Element.
• Custom Commands zählen erst nach Konfiguration. Wer Klicks in eigene Commands verpackt, muss sie in Cypress Cloud nachtragen.

Die Konfiguration liegt in Cypress Cloud im Tab App Quality der Projekteinstellungen. Dort ergänzt du Befehle mit ihrem Namen, wie er im Testcode steht, ohne das Präfix cy.

Das Beispiel aus der Doku nutzt Befehle aus dem Plugin cypress-real-events. Eigene Custom Commands trägst du genauso ein. Ein Rat aus der Praxis: Nimm nur Commands auf, die wirklich mit einem Element arbeiten. Sonst steigt der Score, ohne dass mehr geprüft wird.

Code Coverage misst, welche Zeilen, Branches und Funktionen deines Quellcodes während eines Tests gelaufen sind. In Cypress liefert das Plugin @cypress/code-coverage diese Daten. Es instrumentiert deinen Code aber nicht selbst. Das übernimmt Istanbul, meist über babel-plugin-istanbul. Das Plugin sammelt danach die Daten und erzeugt mit nyc einen Report im Ordner coverage.

UI Coverage schaut von der anderen Seite. Es misst die Oberfläche so, wie ein Mensch sie erlebt. Kein Build Schritt, keine Instrumentierung, dafür Cypress Cloud als Voraussetzung. Ein Button kann zu hundert Prozent Code Coverage gehören und trotzdem nie geklickt worden sein, weil ein anderer Test denselben Handler aufruft. Umgekehrt sagt dir UI Coverage nichts über einen Fehlerzweig im Backend.

Dazu kommt eine dritte Perspektive: Barrierefreiheit. Cypress Accessibility und Prüfungen mit axe beantworten, ob Menschen mit Screenreader oder Tastatur die Oberfläche überhaupt bedienen können. Die Tabelle zeigt die drei Blickwinkel nebeneinander.

Eine grüne Pipeline ist ein Versprechen. UI Coverage zeigt dir, wie groß dieses Versprechen wirklich ist. Ein Checkout mit drei ungetesteten Buttons ist kein getesteter Checkout, egal wie viele Specs grün sind.

Gleichzeitig ist der Score kein Qualitätsurteil. Die Doku sagt es klar: Coverage misst, ob ein Test ein Element berührt, nicht ob er das gewünschte Verhalten bestätigt. Ein Test, der alles klickt und nichts prüft, hat hohe Coverage und null Aussagekraft. Gute Bewertung kombiniert deshalb drei Blicke:

• Abdeckung: Welche Views und Elemente fehlen? Das liefert UI Coverage.
• Aussagekraft: Prüft jeder Test ein Ergebnis, das ein Mensch sehen würde? Das klärt ein Review.
• Stabilität: Läuft der Test zuverlässig, ohne Flakiness? Das zeigt die Run Historie.

Für Merge Regeln gibt es die Results API. Das Modul @cypress/extract-cloud-results holt den Report nach cypress run --record im selben CI Build ab. Damit kannst du einen Build bei einer Schwelle scheitern lassen oder nur neue Lücken blockieren.

Für bestehende Apps mit Altlasten empfiehlt die Doku den Baseline Vergleich. Er vergleicht die Anzahl ungetesteter Elemente pro View mit einem gespeicherten Stand. Der Grund ist spannend: Ein neuer Test kann eine ganze Seite bisher unbekannter Elemente sichtbar machen und den Prozentwert senken, obwohl deine Abdeckung besser geworden ist.

Spannend wird UI Coverage, sobald ein KI Agent die Daten liest. Über Cypress Cloud MCP bekommt dein Agent drei lesende Tools dafür:

• cypress_get_ui_coverage_report: Score, getestete und ungetestete Elemente und Links, dazu die fünf riskantesten Views.
• cypress_get_ui_coverage_views: alle Views, sortiert nach ungetesteten Elementen.
• cypress_get_ui_coverage_elements: die interaktiven Elemente eines Runs, filterbar nach getestet oder ungetestet und nach View.

Damit fragst du deinen Agenten nicht mehr nur, warum ein Test rot ist. Du fragst, wo Tests fehlen. Der Agent nimmt die riskanteste View, listet die ungetesteten Elemente und schlägt Tests vor. Die Doku rät, View für View vorzugehen und nicht alles auf einmal anzufassen. In OpenCode verbindest du den Server einmal, danach stehen die Tools in jedem Projekt bereit.

Hier liegt aber auch die Falle. Ein Agent, der auf Coverage optimiert, schreibt gern Tests, die alles klicken und nichts prüfen. Die Doku warnt genau davor. Bei NCA gilt deshalb:

• Der Agent schreibt Tests, ein Mensch reviewt Absicht, Selektoren und Assertions und gibt frei.
• Bestehende Testdateien sind geschützt. Der Agent ergänzt, er schwächt nichts ab.
• Quality Gates in CI laufen zuerst: statische Analyse, Unit Tests, funktionale Tests und Cypress E2E.
• Der Agent arbeitet gegen eine lokale Entwicklungsumgebung mit Fake Daten, nie gegen Produktionsdaten.

Wie Agenten gegen fachliche Anforderungen testen, zeigt unser Artikel zu agentischen Akzeptanztests. Wie du den Ablauf mit klaren Freigaben baust, steht bei den Governed Agent Loops. Und wie realistische Daten lokal entstehen, beschreibt der Beitrag zu Faker Testdaten für lokale Entwicklung.

UI Coverage ist ein starkes Werkzeug. Es hat aber klare Grenzen, die du vor der Einführung kennen solltest:

• Berührt heißt nicht geprüft. Der Score sagt nichts darüber, ob deine Assertions das richtige Verhalten absichern.
• Ohne Test Replay kein Report. Ein Run ohne Test Replay erzeugt laut Doku keinen Report. Lokale Läufe ohne Aufzeichnung tauchen nicht auf.
• Konfiguration braucht Pflege. Views gruppieren, Rauschen filtern, eigene Commands eintragen: Das ist Arbeit, sonst lügt der Score in beide Richtungen.
• Prozentwerte schwanken. Neue Tests machen neue Elemente sichtbar. Darum ist der Baseline Vergleich oft fairer als eine harte Schwelle.

Zur Verfügbarkeit: Cypress führt UI Coverage als Premium Lösung. Sie steckt nicht automatisch in einem Cloud Plan, sondern kommt als Zusatz für die Pläne Team, Business und Enterprise. Cypress bietet dafür eine Testphase an. Konkrete Konditionen klärst du direkt mit Cypress.

Zum Datenschutz: Cypress Cloud ist ein US Anbieter. UI Coverage arbeitet mit Test Replay, also mit DOM Snapshots deiner Anwendung. Was in deinen Testdaten steht, landet dort. Deshalb gehören in aufgezeichnete Runs nur Fake Daten, nie echte Kundendaten. Wer volle Datenhoheit braucht, bleibt bei lokaler Code Coverage und axe Prüfungen und verzichtet auf die Cloud Auswertung.

Wir sehen UI Coverage als Werkzeug für ein Gespräch im Team, nicht als Ziel. Die spannende Frage lautet nie: Wie kommen wir auf einen höheren Score? Sie lautet: Welche ungetestete View würde uns am meisten wehtun, wenn sie morgen kaputt ist? Daraus entsteht eine Liste, die Teams selbst abarbeiten können. So übernimmt das Team die Qualität, statt sie an eine einzelne Testperson abzugeben.

Mit KI Agenten wird diese Haltung noch wichtiger. Agenten schreiben schnell viele Tests. Ohne Review entsteht daraus eine Suite, die alles anfasst und wenig beweist. Wie wir Code Qualität mit KI Agenten sichern, gilt hier eins zu eins. Tests sind für uns außerdem lebende Spezifikation: Jede neue Assertion beschreibt, was die Anwendung tun soll.

Weiterlesen: unsere Übersicht zu Accessibility Testing Tools, die Einordnung der Risiken beim Vibe Coding und die KI Weiterbildung für Entwicklerteams, wenn dein Team den Umgang mit Agenten und Tests gemeinsam lernen will.

Passend dazu im NCA Cypress Glossar: Cypress Custom Commands, die du für UI Coverage als Interaktionsbefehle einträgst, und Cypress Parallelisierung für schnelle aufgezeichnete Runs.

Die wichtigsten Antworten zu UI Coverage in Cypress Cloud: Setup, Unterschied zu Code Coverage, Custom Commands, KI Agenten und Datenschutz.