Testautomatisierung Bewährte Methoden

Lesezeit: 16 min

28 Juli 2026

Cypress Code-Coverage einrichten: Praktisches Tutorial

Q: Unterstützt Cypress Code Coverage von Haus aus?

Nein. Cypress braucht das Plugin @cypress/code-coverage und einen instrumentierten Anwendungs-Build. Konfigurieren Sie Istanbul über Vite, Webpack oder Babel, um Coverage-Zähler einzufügen, und installieren Sie dann das Plugin, um diese Daten zu sammeln und zu melden.

Q: Kann ich Code Coverage aus parallel ausgeführten Tests kombinieren?

Ja. Speichern Sie das .nyc_output/-Verzeichnis jedes CI-Workers als Artefakt, laden Sie sie in ein gemeinsames Verzeichnis herunter und führen Sie dann nyc merge gefolgt von nyc report aus. Überspringen Sie den Merge, erscheinen nur die Ergebnisse eines Workers.

Q: Wie schließe ich Testdateien und node_modules aus dem Coverage-Report aus?

Fügen Sie ein "exclude"-Array zu Ihrer .nycrc-Datei hinzu, das Muster wie node_modules/**, **/*.test.js und Konfigurationsdateien auflistet. Ohne Ausschlüsse sinkt der gemeldete Prozentsatz künstlich, da irrelevante Dateien gegen die Gesamtzahl zählen.

Die CI-Pipeline ist grün, und Ihre Teammitglieder sitzen in einem Code-Review und fragen sich: Was beeinflussen manche dieser Tests eigentlich? Eine bestehende Suite sagt nichts darüber aus, ob Ihre Validierungslogik, Fehlerbehandlung oder Berechtigungsprüfungen jemals ausgeführt wurden. Das könnte der Grund sein, warum Ihr Team ein Feature ausliefert und Wochen später Defekte in der Produktion auftauchen. Cypress, ein Frontend-Testautomatisierungstool für Regressionstests, ist hier eine beliebte Lösung. Dieser Leitfaden führt Sie durch die richtige Einrichtung von Cypress Code Coverage. Er behandelt die Instrumentierung Ihres Builds, die Registrierung des Plugins, das Zusammenführen paralleler CI-Läufe und die Auswertung der Reports.

Martin Koch Autor

Pavel Vehera Geprüft

Wichtigste Erkenntnisse

Coverage zeigt, was Ihre Tests tatsächlich überspringen. Eine Suite kann bei jedem Lauf bestehen, während Rabattlogik, Zahlungsvalidierung oder Fehler-Fallback-Pfade komplett unberührt bleiben.
Drei Schritte bringen Coverage zum Laufen: den Build mit Istanbul instrumentieren, das Plugin in cypress.config.js registrieren und die Support-Datei importieren. Überspringen Sie einen davon, und Ihre Reports kommen leer zurück.
Der Report verfolgt vier Metriken: Statements, Branches, Functions und Lines. Branch Coverage deckt tendenziell am meisten auf, da eine Funktion volle Line Coverage zeigen kann, während eine Seite einer Bedingung nie ausgeführt wird.
Parallele CI-Läufe erfordern manuelles Zusammenführen. Jeder Worker muss sein .nyc_output-Verzeichnis als Artefakt speichern, dann führen Sie alles mit nyc merge zusammen, bevor Sie den finalen Report generieren. Überspringen Sie diesen Schritt, überleben nur die Daten eines Workers.

Dieser Leitfaden führt Sie durch die richtige Einrichtung von Cypress Code Coverage, damit eine grüne Pipeline auch wirklich etwas bedeutet 👇

Was ist Code Coverage in Cypress?

Code Coverage verfolgt, welche Teile Ihres Quellcodes während der Ausführung Ihrer Cypress-Tests laufen. Stellen Sie es sich als Karte vor, die genau zeigt, welche Routen Ihre Tests durch die Codebasis nehmen und welche Ecken sie nie besuchen.

Hier ist die entscheidende Unterscheidung: Ihr Cypress-Report zeigt bestanden oder fehlgeschlagen. Coverage zeigt, ob der Test tatsächlich die relevante Logik erreicht hat. Ein Test kann eine Checkout-Seite laden, auf Absenden klicken und eine Erfolgsmeldung sehen. Er besteht, aber wenn er nie Ihre Rabattberechnung oder Zahlungsvalidierung ausgelöst hat, bleiben diese Bereiche ungetestet hinter einem grünen Häkchen.

Cypress kann das allein nicht messen. Ihre Anwendung braucht zuerst eine Instrumentierung, üblicherweise über Istanbul, das während des Builds Zähler um Codeblöcke herum einfügt. Wenn Cypress mit Ihrer App interagiert, zeichnen diese Zähler jeden Treffer auf. Von dort sammelt das Plugin @cypress/code-coverage die Daten und übergibt sie an NYC für das Reporting.

Das ergibt eine dreiteilige Kette, von der Ihr Setup abhängt:

Instrumentierung: Istanbul fügt Zähler in Ihren Test-Build ein
Ausführung: Cypress läuft und löst diese Zähler aus
Sammlung: das Plugin sammelt die Daten, und NYC macht daraus einen Report

Überspringen Sie den Instrumentierungsschritt, hat der Rest der Kette nichts zu sammeln. Das ist der mit Abstand häufigste Grund, warum Teams am Ende auf einen leeren Report starren.

Cypress Code Coverage vs. UI Coverage

Code Coverage und UI Coverage beantworten unterschiedliche Fragen, und sie zu verwechseln führt in beide Richtungen zu falscher Sicherheit.

Ansatz	Was er misst	Instrumentierung erforderlich	Am besten geeignet für
Code Coverage	Ausgeführte Statements, Branches, Functions und Lines	Ja, über Istanbul	Ungetestete Logikpfade, Bedingungen und Fehlerbehandlungen finden
UI Coverage	Interaktive Elemente und Anwendungszustände, die von Tests durchlaufen wurden	Nein	Buttons, Formulare und Screens finden, die Ihre Testsuite nie berührt

Code Coverage deckt Anwendungslogik auf, die Ihre Tests nie ausgeführt haben. UI Coverage deckt Oberflächenelemente auf, die Ihre Tests nie berührt haben: nie geklickte Buttons, nie ausgefüllte Formularfelder, nie ausgelöste Zustände. Eine Testsuite kann 90 % Code Coverage erreichen, während ganze Bereiche der Oberfläche ungetestet bleiben, da ein einzelner Codepfad oft mehrere unterschiedliche Screens oder Interaktionen bedient. Die beiden Metriken beantworten getrennte Fragen, und eine als Ersatz für die andere zu lesen verdeckt reale Lücken sowohl in der Logik als auch in der Oberfläche.

Warum Code Coverage für Cypress-Tests einrichten

Coverage deckt auf, was Ihre Regressionssuite still ignoriert. Tests durchlaufen möglicherweise den Happy Path bei der Kontoerstellung, ohne je die Prüfung zu treffen, die doppelte E-Mail-Adressen blockiert, oder ein Preismodul wird nur mit Standardrabatten getestet, während Promo-Codes und Mengenrabatt-Randfälle komplett unberührt bleiben.

Sobald Coverage-Daten vorliegen, verwandeln sie diese blinden Flecken in etwas, worauf Ihr Team reagieren kann, statt in etwas, das alle einfach für in Ordnung halten. Hier zahlt sich diese Sichtbarkeit in der Praxis aus:

Ein Pull Request kann zeigen, ob Tests bestanden haben und ob der neue Code tatsächlich erreicht wurde, was es schwerer macht, einen Test zu mergen, der die richtige Seite öffnet, ohne die Logik zu berühren, die er eigentlich prüfen soll
Wenn Ihr Team 200 Browsertests ausführt und die CI-Zeit stetig wächst, deckt Coverage oft Duplikate auf, etwa zehn verschiedene Szenarien, die denselben Login-Flow durchlaufen
Mit dieser Sichtbarkeit lassen sich teure E2E-Tests gegen schnellere Component- oder API-Tests austauschen, ohne die Abdeckung derselben Codepfade zu verlieren

Code Coverage wird bei E2E-Tests normalerweise nicht gemessen. Was Cypress bietet, ist eine Funktion, die eine Liste von UI-Elementen liefert, mit denen kein Test interagiert hat. Das kann wertvoll sein, wenn man eine unüberschaubare Menge an Tests hat, die man nicht gut versteht, und sehen möchte, was nicht "abgedeckt" wird.

Yogurt8 Posted in Reddit

Schritt-für-Schritt-Einrichtung

Coverage zum Laufen zu bringen bedeutet, Ihr Build-Tool, Test-Framework und Reporting-Plugin zu koordinieren, und die Reihenfolge ist wichtiger, als es scheinen mag. Verpassen Sie einen Schritt, etwa vergessen Sie, Ihren Build vor dem Testlauf zu instrumentieren, landen Sie beim Debuggen eines leeren Reports statt beim Lesen eines nützlichen.

Bevor Sie beginnen, stellen Sie sicher, dass Node.js und npm installiert sind, Sie Schreibzugriff auf die Build-Konfiguration Ihres Repos (Vite-, Webpack- oder CRA-Setup) haben und die Berechtigung, cypress.config.js zu bearbeiten. Hier ist die Abfolge:

Plugin installieren. Führen Sie npm install --save-dev @cypress/code-coverage im Root Ihres Projekts aus. Das Plugin wird mit gebündeltem NYC ausgeliefert, eine separate NYC-Installation ist also nicht nötig. Das Instrumentierungs-Paket hängt von Ihrer Build-Pipeline ab:
```
# Vite
npm install --save-dev vite-plugin-istanbul

# Babel oder Webpack
npm install --save-dev babel-plugin-istanbul
```
Ihren Anwendungscode instrumentieren. Dieser Schritt bringt die meisten Setups zu Fall, da Cypress Ihren Quellcode nicht automatisch instrumentiert. Fügen Sie bei Vite-Projekten das Plugin direkt zu Ihrer Konfiguration hinzu:
```
import { defineConfig } from 'vite'
import istanbul from 'vite-plugin-istanbul'

export default defineConfig({
  plugins: [
    istanbul({
      include: 'src/*',
      exclude: ['node_modules', 'test/'],
      extension: ['.js', '.jsx', '.ts', '.tsx'],
      requireEnv: false,
    }),
  ],
})
```
Sobald dieses Plugin läuft, erkennt Cypress Coverage automatisch aus window.__coverage__ ohne weitere Verdrahtung. Verwenden Sie bei Webpack stattdessen babel-plugin-istanbul in Ihrer Babel-Konfiguration. Create-React-App-Projekte können react-app-rewired mit Istanbul-Middleware kombinieren. Unabhängig davon, welchen Bundler Ihr Projekt verwendet, braucht der Test-Build Coverage-Zähler, die nie in die Produktion ausgeliefert werden.

Das Plugin in der Cypress-Konfiguration registrieren. Öffnen Sie cypress.config.js (oder .ts) und registrieren Sie die Coverage-Task innerhalb von setupNodeEvents, dann geben Sie am Ende config zurück. Wird dieses Return übersprungen, bricht das Setup lautlos.

import { defineConfig } from 'cypress'
import registerCodeCoverageTasks from '@cypress/code-coverage/task'

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      registerCodeCoverageTasks(on, config)
      return config
    },
  },
  component: {
    setupNodeEvents(on, config) {
      registerCodeCoverageTasks(on, config)
      return config
    },
  },
})

Den Support-File-Import hinzufügen. Fügen Sie import '@cypress/code-coverage/support' sowohl in cypress/support/e2e.ts als auch in cypress/support/component.ts hinzu. Wird er nur in e2e.ts importiert, wird E2E-Coverage verdrahtet, aber Component-Test-Coverage bleibt unerfasst.
NYC konfigurieren. Erstellen Sie .nycrc oder .nycrc.json im Projekt-Root. Setzen Sie "all": true, damit jede Quelldatei einbezogen wird, auch solche, die während der Tests nie geladen werden, und fügen Sie "exclude"-Muster für node_modules, Testdateien und generierten Code hinzu. Ohne das wirkt der gemeldete Prozentsatz künstlich niedrig.
Cypress ausführen und den Report prüfen. Führen Sie npx cypress run in Ihrem Terminal aus. Coverage-Daten landen in .nyc_output/, und Reports werden im Verzeichnis coverage/ generiert. Öffnen Sie coverage/lcov-report/index.html in einem beliebigen Browser für die interaktive Aufschlüsselung, farbcodiert danach, wie gut jede Datei abgedeckt ist.

Coverage für Component-Tests einrichten

Component-Testing mountet einzelne UI-Bausteine, etwa einen Button oder ein Formular, ohne Ihre gesamte Anwendung zu laden. Die Instrumentierung folgt hier demselben Prinzip, aber die Konfiguration braucht eine kleine Anpassung, da Components über einen anderen Runner gemountet werden als E2E-Tests.

Stellen Sie zunächst sicher, dass Ihr Bundler den Component-Code während des Dev-Server-Builds instrumentiert. Ist vite-plugin-istanbul bereits für E2E registriert, deckt es typischerweise auch Component-Tests ab. Stellen Sie bei Webpack-Setups sicher, dass babel-plugin-istanbul auf Ihre Component-Quelldateien angewendet wird, nicht nur auf den Einstiegspunkt Ihrer App, da Component-Tests den normalen Bootstrap oft umgehen.

Registrieren Sie das Plugin auf dieselbe Weise wie bei E2E: require('@cypress/code-coverage/task')(on, config) innerhalb Ihrer Component-Konfiguration. Importieren Sie dann die Support-Datei in cypress/support/component.js.

Ein Haken: Components, die ihre Abhängigkeiten mocken, erzeugen irreführende Zahlen. Wenn Sie eine Component mounten und deren API-Client stubben, taucht der echte Client-Code nie im Report auf. Das ist erwartbar. Der Fix besteht darin, Ergebnisse zu kombinieren, Component- und E2E-Tests gemeinsam auszuführen und deren Outputs zusammenzuführen, was der nächste Abschnitt behandelt.

Das Erfassen von Code Coverage mit Cypress wird deutlich nützlicher, sobald Sie kombinierte Daten statt isolierter Component-Läufe betrachten.

Testlücken überschneiden sich oft mit anforderungsbezogenen Problemen. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Lösung, verbindet Testabdeckung direkt mit Anforderungen und Geschäftslogik. So sieht Ihr Team, welche Zeilen ausgeführt wurden und ob jede kritische Anforderung tatsächlich durch eine Validierung abgedeckt ist. aquas KI Intelligence ist über RAG in Ihrer eigenen Projektdokumentation verankert, sodass sie statt generischer Vorschläge ungetestete Anforderungen markiert und Testfälle generiert, die zur tatsächlichen Terminologie und den Workflows Ihres Teams passen. Sie erhalten Echtzeit-Dashboards zur Anforderungsabdeckung, automatisierte Lückenerkennung und vollständige Traceability von Geschäftsanforderung bis zur Testausführung. Darüber hinaus verfügt aqua über native Integrationen mit Jira für bidirektionale Synchronisation, Azure DevOps, Confluence, über 12 weitere Tools und eine REST-API, sodass Coverage-Daten dort landen, wo Ihr Team bereits arbeitet.

Steigern Sie die Effizienz im Testmanagement um 80 %

aqua kostenlos testen

Coverage aus parallelen Testläufen zusammenführen

Jeder Worker sollte seine Coverage-JSON unter einem eindeutigen Namen speichern statt unter dem Standardpfad .nyc_output/, da parallele Jobs, die in dasselbe Verzeichnis schreiben, sich gegenseitig die Daten überschreiben. Sobald jeder Worker fertig ist, laden Sie alle benannten Artefakte in einen Ordner herunter und führen dann Merge und Report aus einem sauberen Output-Verzeichnis heraus aus:

rm -rf .nyc_output
mkdir -p .nyc_output
npx nyc merge coverage-parts .nyc_output/out.json
npx nyc report 
  --temp-dir .nyc_output 
  --reporter=html 
  --reporter=lcov 
  --reporter=text-summary

Das Flag –temp-dir teilt dem Report-Schritt genau mit, welchen zusammengeführten Output er lesen soll, was jede Unklarheit über die Datenquelle beseitigt.

Die meisten CI-Plattformen, darunter GitHub Actions, GitLab CI, CircleCI und Jenkins, unterstützen das Sammeln von Artefakten. Konfigurieren Sie jeden Worker so, dass er sein .nyc_output/-Verzeichnis als Artefakt speichert, und stellen Sie sicher, dass jeder in einen eindeutig benannten Pfad schreibt, damit Worker sich nicht gegenseitig überschreiben. Sobald jeder Worker fertig ist, lädt ein finaler Reporting-Job alle Artefakte in ein gemeinsames .nyc_output/-Verzeichnis herunter. Von dort aus:

Führen Sie nyc merge .nyc_output merged-coverage.json aus, um die Rohdaten zu kombinieren
Führen Sie nyc report --reporter=html --reporter=text --reporter=lcov aus, um den vereinheitlichten Report zu generieren

Dieselbe Logik gilt beim Kombinieren von Component- und E2E-Coverage. Führen Sie sie als separate Jobs aus, bewahren Sie beide Output-Verzeichnisse auf, führen Sie sie in einem dritten Job zusammen, und Sie erhalten einen Report, der sowohl isolierte Component-Logik als auch vollständige Browser-Szenarien widerspiegelt.

Den Coverage-Report verstehen

Ein Cypress-Coverage-Report gliedert sich in vier Metriken statt in einen einzelnen Prozentsatz, und jede beleuchtet eine andere Art von Lücke in Ihrer Testsuite. Sie zusammen zu lesen ergibt ein deutlich genaueres Bild als ein Blick auf die Gesamtzahl.

Bevor Sie sich die Aufschlüsselung nach Datei ansehen, hilft es zu wissen, was jede Metrik tatsächlich misst:

Statements: einzelne ausführbare Anweisungen
Branches: ob beide Seiten einer Bedingung (if/else, switch, ternär) erreicht wurden
Functions: ob jede deklarierte Funktion mindestens einmal aufgerufen wurde
Lines: welche Quellzeilen ausgeführt wurden, wobei eine Zeile mehrere Statements enthalten kann

Branch Coverage deckt in der Regel am meisten auf. Eine Funktion kann volle Line Coverage zeigen, während eine Seite einer wichtigen Bedingung kein einziges Mal ausgeführt wird.

Der HTML-Report zeigt einen farbcodierten Dateibaum: Grün für starke Abdeckung, Gelb für teilweise, Rot für ernste Lücken. Klicken Sie in eine beliebige Datei, sehen Sie annotierten Quellcode mit Ausführungszählern am Rand, die zeigen, wie oft jede Zeile lief. Eine Zeile, die 247 Mal getroffen wurde, steckt wahrscheinlich in einer Schleife, während eine Zeile, die einmal getroffen wurde, ein Randfall-Handler sein könnte, den niemand direkt testet.

Achten Sie besonders auf eine Einstellung: Standardmäßig meldet NYC nur Dateien, die während der Tests tatsächlich geladen wurden. Diese Standardeinstellung kann Ihren Prozentsatz aufblähen, da ein Feature, das niemand überhaupt getestet hat, einfach aus der Berechnung verschwindet, statt gegen sie zu zählen. Setzen Sie „all“: true zusammen mit einem expliziten Include-Muster, damit jede passende Quelldatei erscheint, auch solche, die Tests nie berührt haben, mit 0 % Abdeckung.

Cypress als Tool hilft dabei, E2E-User-Workflows zu validieren, aber nicht unbedingt die Code Coverage. Es gibt andere Tools wie SonarQube/Codecov, die bei der Bewertung der Code Coverage helfen können. Wir nutzen unterschiedliche Tools für unterschiedliche Zwecke. Und man findet vielleicht kein All-in-One-Tool.

Special-Shoulder-279 Posted in Reddit

Wie man Cypress-Coverage-Schwellenwerte in CI durchsetzt

Ein Coverage-Report hilft nur, wenn etwas darauf reagiert. NYC unterstützt das Fehlschlagen eines Builds, wenn die Coverage unter einen festgelegten Schwellenwert fällt, sodass Ihre Pipeline eine Mindestgrenze durchsetzt, statt nur eine Zahl anzuzeigen, die niemand prüft.

Führen Sie es direkt über die Kommandozeile aus:

npx nyc report 
  --check-coverage 
  --statements 80 
  --branches 75 
  --functions 80 
  --lines 80

Oder legen Sie es einmal in .nycrc.json fest, damit jeder Lauf automatisch dieselben Schwellenwerte anwendet:

{
  "all": true,
  "include": ["src/**/*.{js,jsx,ts,tsx}"],
  "exclude": [
    "**/*.test.*",
    "**/*.spec.*",
    "src/generated/**"
  ],
  "reporter": ["text-summary", "html", "lcov"],
  "check-coverage": true,
  "statements": 80,
  "branches": 75,
  "functions": 80,
  "lines": 80
}

Branch Coverage braucht in der Regel einen etwas niedrigeren Schwellenwert als Statements oder Lines, da bedingte Logik die Anzahl der Pfade vervielfacht, die eine Testsuite treffen muss. Branches zu früh zu hoch anzusetzen blockiert Merges tendenziell wegen Randfällen, die noch niemand erreicht hat, nicht wegen echter Regressionen.

Häufige Setup-Probleme und wie man sie behebt

Selbst ein sorgfältiges Setup stößt unterwegs auf Probleme, und die meisten davon lassen sich auf eine Handvoll wiederkehrender Ursachen zurückführen. Zu wissen, was zuerst zu prüfen ist, spart eine Menge Zeit beim Raten.

Hier sind die Probleme, die am häufigsten auftreten, und was Sie zuerst prüfen sollten:

Leere oder Null-Prozent-Reports: bedeutet meist, dass Ihre Anwendung nicht instrumentiert ist. Prüfen Sie, ob Istanbul- oder Babel-Instrumentierung für Ihren Test-Build läuft, und stellen Sie sicher, dass NODE_ENV nicht auf production gesetzt ist, was Dev-only-Plugins deaktiviert.
Coverage spiegelt nur einen Worker wider: parallele Läufe überschreiben sich gegenseitig. Speichern Sie den Output jedes Workers in einem eindeutig benannten Verzeichnis und führen Sie sie dann mit NYC zusammen, bevor Sie den finalen Report generieren.
Coverage wird den falschen Dateien zugeordnet: defekte Source Maps sind die Ursache. Aktivieren Sie sourcemap: true in Ihrer Build-Konfiguration und bestätigen Sie, dass .map-Dateien zusammen mit Ihrem Test-Build generiert werden.
Plugin-Tasks nicht registriert: Ihnen fehlt require('@cypress/code-coverage/task')(on, config) innerhalb von setupNodeEvents. Ohne das kann Cypress Coverage-Daten weder speichern noch abrufen.
NYC-Konfiguration wird ignoriert: prüfen Sie .nycrc auf abschließende Kommas oder fehlerhafte Exclude-Muster. Führen Sie npx nyc report manuell aus, um zu bestätigen, dass Ihre Einstellungen tatsächlich angewendet werden.
Coverage sinkt nach einem Refactoring: das bedeutet oft nur, dass alter Code nur beiläufig „getestet“ wurde. Prüfen Sie den Diff und entscheiden Sie dann, ob der betroffene Bereich neue Tests braucht.
Full-Stack-Coverage-Konfiguration wird nicht erkannt: in @cypress/code-coverage v4 zog die Backend-Coverage-Konfiguration von env.codeCoverage nach expose.codeCoverage um, nachdem der ältere Cypress.env()-Workflow in Cypress 16 entfernt wurde. Jedes Full-Stack-Setup, das noch auf env.codeCoverage verweist, muss für aktuelle Plugin-Versionen aktualisiert werden.

Best Practices für die Nutzung von Code Coverage in Cypress

Coverage zum Laufen zu bringen ist nur die halbe Arbeit. Sie in den Arbeitsalltag Ihres Teams einzubauen, von PR-Reviews bis zur Sprint-Planung, macht aus rohen Zahlen etwas, worauf man handeln kann.

Die folgenden Praktiken decken die Bereiche ab, in denen Teams mit dem geringsten laufenden Aufwand den größten Nutzen erzielen:

Behandeln Sie Coverage nicht als Qualitätsnachweis. Ein Test kann eine Zeile ausführen, ohne je ihr Verhalten zu prüfen. Coverage sagt Ihnen, was lief, nicht wie gut es verifiziert wurde.
Setzen Sie unterschiedliche Schwellenwerte für unterschiedlichen Code. Zahlungslogik und Authentifizierung verdienen strenge Branch Coverage. Konfigurations-Wrapper und generierte Dateien können lockerere Schwellenwerte tragen. NYC unterstützt Schwellenwerte pro Verzeichnis, nutzen Sie das.
Kombinieren Sie Coverage über Testarten hinweg. Führen Sie Component-, E2E- und API-Test-Coverage in einem Report zusammen, damit Ihre Cypress-Suite nicht für jedes fehlende interne Utility bestraft wird.
Verfolgen Sie Coverage-Deltas in Pull Requests. Tools wie Codecov oder Coveralls können direkt in PRs kommentieren, sodass offensichtlich wird, wenn neuer Code ohne Tests ausgeliefert wird.
Nutzen Sie Coverage, um redundante Tests zu kürzen. Wenn mehrere E2E-Tests dieselben Codepfade treffen, tauschen Sie einige gegen schnellere Component- oder API-Tests, ohne an Sicherheit zu verlieren.
Dokumentieren Sie Ihre Ausschlüsse. Generierter Code und Vendor-Adapter überladen Reports, aber Ausschlüsse ohne Erklärung neigen dazu, mit der Zeit echte Lücken zu verdecken.

Coverage-Reports geben Ihrem Team wertvolle Einblicke in den Code. Sie sagen Ihnen jedoch nicht, ob Ihre Teststrategie das abdeckt, was das Business tatsächlich braucht. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Plattform, adressiert genau das, indem sie Testausführung zurück auf Anforderungen und User Storys abbildet. So rutscht nichts Kritisches unbemerkt durch. Die KI Intelligence ist speziell für QA trainiert und in der eigenen Projektdokumentation Ihres Teams verankert. Sie markiert Coverage-Lücken gegen die tatsächlichen Spezifikationen Ihres Teams und generiert Testfälle, die zum echten Projektkontext passen statt zu generischen Vorlagen. Echtzeit-Dashboards zeigen genau, welche Anforderungen noch keine Validierung haben, und mit über 10 nativen Automatisierungsintegrationen, darunter Jenkins, JMeter, SoapUI, Ranorex, Oracle- und MSSQL-Datenbanken, PowerShell, UnixShell und Capture. Damit fließen Coverage-Daten direkt in die Tools, mit denen Ihr Team bereits arbeitet.

Erreichen Sie 100 % strategische Testabdeckung mit KI-gestützter Anforderungs-Traceability

aqua kostenlos testen

Fazit

Die Einrichtung von Cypress Code Coverage gibt Ihrem Team ein klares Bild davon, was tatsächlich getestet wird, statt eines binären Bestanden-oder-Durchgefallen. Sie erfordert echte Setup-Arbeit: Instrumentierung, Plugin-Konfiguration und sorgfältiges Zusammenführen über parallele Läufe hinweg. Der Gewinn ist eine Regressionssuite, der Ihr Team vertrauen kann, eine, die Lücken in Validierungslogik und Fehlerbehandlung markiert, bevor sie die Produktion erreichen.

Auf dieser Seite:

Beschleunigen Sie Ihre Releases x2 mit aqua

Gratis starten

FAQ

Unterstützt Cypress Code Coverage von Haus aus?

Nein. Cypress braucht das Plugin @cypress/code-coverage und einen instrumentierten Anwendungs-Build. Konfigurieren Sie Istanbul über Vite, Webpack oder Babel, um Coverage-Zähler einzufügen, und installieren Sie dann das Plugin, um diese Daten zu sammeln und zu melden.

Kann ich Code Coverage aus parallel ausgeführten Tests kombinieren?

Ja. Speichern Sie das .nyc_output/-Verzeichnis jedes CI-Workers als Artefakt, laden Sie sie in ein gemeinsames Verzeichnis herunter und führen Sie dann nyc merge gefolgt von nyc report aus. Überspringen Sie den Merge, erscheinen nur die Ergebnisse eines Workers.

Welche Metriken zeigt ein Cypress-Code-Coverage-Report?

Vier: Statements, Branches, Functions und Lines. Branch Coverage ist tendenziell am nützlichsten, um ungetestete Logik zu erkennen, da sie Bedingungen erfasst, bei denen nur ein Pfad je ausgeführt wird.

Bedeutet 100 % Coverage, dass meine Anwendung vollständig getestet ist?

Nein. Coverage zeigt nur, dass eine Zeile ausgeführt wurde, nicht dass ein Test ihr Verhalten verifiziert hat. Ein Szenario kann eine Funktion auslösen, ohne irgendetwas Bedeutsames zu prüfen, sodass hohe Coverage-Zahlen immer noch echtes Testdesign dahinter brauchen.

Wie schließe ich Testdateien und node_modules aus dem Coverage-Report aus?

Fügen Sie ein "exclude"-Array zu Ihrer .nycrc-Datei hinzu, das Muster wie node_modules/**, **/*.test.js und Konfigurationsdateien auflistet. Ohne Ausschlüsse sinkt der gemeldete Prozentsatz künstlich, da irrelevante Dateien gegen die Gesamtzahl zählen.

Warum zeigt mein Coverage-Report 0 % für Dateien, von denen ich weiß, dass sie getestet sind?

Das deutet meist auf ein Source-Map-Problem oder eine Datei hin, die Ihr Bundler nie instrumentiert hat. Bestätigen Sie, dass sourcemap: true in Ihrer Build-Konfiguration gesetzt ist und dass die Datei unter die Istanbul- oder Babel-Instrumentierungsregeln Ihres Bundlers fällt.