{
"doc": {
"id": "app/tooling/code-coverage",
"title": "Measuring Code Coverage in Cypress",
"description": "Learn how to measure code coverage in Cypress and the difference between UI Coverage and Code Coverage.",
"section": "app",
"source_path": "/llm/markdown/app/tooling/code-coverage.md",
"version": "3cf5b86b3403f604bdf7f3e35025c3bc3865e02c",
"updated_at": "2026-05-07T17:44:31.931Z",
"headings": [
{
"id": "app/tooling/code-coverage#measure-code-coverage-in-cypress",
"text": "Measure Code Coverage in Cypress",
"level": 1
},
{
"id": "app/tooling/code-coverage#what-youll-learn",
"text": "What you'll learn",
"level": 5
},
{
"id": "app/tooling/code-coverage#introduction",
"text": "Introduction",
"level": 2
},
{
"id": "app/tooling/code-coverage#code-coverage",
"text": "Code Coverage",
"level": 3
},
{
"id": "app/tooling/code-coverage#ui-coverage",
"text": "UI Coverage",
"level": 3
},
{
"id": "app/tooling/code-coverage#instrumenting-code",
"text": "Instrumenting code",
"level": 2
},
{
"id": "app/tooling/code-coverage#using-nyc",
"text": "Using NYC",
"level": 3
},
{
"id": "app/tooling/code-coverage#using-code-transpilation-pipeline",
"text": "Using code transpilation pipeline",
"level": 3
},
{
"id": "app/tooling/code-coverage#e2e-code-coverage",
"text": "E2E code coverage",
"level": 2
},
{
"id": "app/tooling/code-coverage#install-the-plugin",
"text": "Install the plugin",
"level": 3
},
{
"id": "app/tooling/code-coverage#see-code-coverage-summary",
"text": "See code coverage summary",
"level": 3
},
{
"id": "app/tooling/code-coverage#code-coverage-as-a-guide",
"text": "Code coverage as a guide",
"level": 2
},
{
"id": "app/tooling/code-coverage#combining-code-coverage-from-parallel-tests",
"text": "Combining code coverage from parallel tests",
"level": 2
},
{
"id": "app/tooling/code-coverage#e2e-and-unit-code-coverage",
"text": "E2E and unit code coverage",
"level": 2
},
{
"id": "app/tooling/code-coverage#full-stack-code-coverage",
"text": "Full stack code coverage",
"level": 2
},
{
"id": "app/tooling/code-coverage#videos",
"text": "Videos",
"level": 2
},
{
"id": "app/tooling/code-coverage#how-to-instrument-react-scripts-web-application-for-code-coverage",
"text": "How to instrument react-scripts web application for code coverage",
"level": 3
},
{
"id": "app/tooling/code-coverage#get-code-coverage-reports-from-cypress-tests",
"text": "Get code coverage reports from Cypress tests",
"level": 3
},
{
"id": "app/tooling/code-coverage#excluding-code-from-code-coverage-reports",
"text": "Excluding code from code coverage reports",
"level": 3
},
{
"id": "app/tooling/code-coverage#check-code-coverage-robustly-using-3rd-party-tool",
"text": "Check code coverage robustly using 3rd party tool",
"level": 3
},
{
"id": "app/tooling/code-coverage#adding-code-coverage-badge-to-your-project",
"text": "Adding code coverage badge to your project",
"level": 3
},
{
"id": "app/tooling/code-coverage#show-code-coverage-in-commit-status-check",
"text": "Show code coverage in commit status check",
"level": 3
},
{
"id": "app/tooling/code-coverage#checking-code-coverage-on-pull-request",
"text": "Checking code coverage on pull request",
"level": 3
},
{
"id": "app/tooling/code-coverage#examples",
"text": "Examples",
"level": 2
},
{
"id": "app/tooling/code-coverage#see-also",
"text": "See also",
"level": 2
}
]
},
"chunks": [
{
"id": "app/tooling/code-coverage#what-youll-learn",
"doc_id": "app/tooling/code-coverage",
"heading": "What you'll learn",
"heading_level": 5,
"content_markdown": "##### What you'll learn\n\n* The difference between Code Coverage and Cypress's UI Coverage\n* How to instrument your application code for code coverage\n* How to collect code coverage from Cypress tests\n* How to merge code coverage from parallel tests\n* How to collect code coverage from different testing types\n",
"section": "app",
"anchors": [
"what-youll-learn"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 69
},
{
"id": "app/tooling/code-coverage#introduction",
"doc_id": "app/tooling/code-coverage",
"heading": "Introduction",
"heading_level": 2,
"content_markdown": "## Introduction\n\nAs you write more and more end-to-end tests, you will find yourself wondering - do I need to write more tests? Are there parts of the application still untested? Are there parts of the application that perhaps are tested too much?\n\nCypress offers a couple of solutions to help answer these questions:\n\n* **[Code coverage](#Code-Coverage)** - find out which lines of the application's source code were executed\n* **[UI coverage](#UI-Coverage)** - find out which parts of the UI were tested\n\n### Code Coverage\n\nCode coverage is a metric that helps you understand how much of your application code is covered by your tests. If there are important sections of the application's logic that **were not** executed from the tests, then a new test can be added to ensure that the application logic for these sections is also tested.\n\nComputing the source code lines that were executed during the test is done through **code coverage**. Code coverage requires inserting additional counters into your source code before running it using **instrumentation**. This document will be focused on code coverage and the instrumentation required to set it up.\n\n### UI Coverage\n\nUI Coverage is a visual test coverage report based on the interactive elements that make up your application. It highlights areas of missed test coverage directly within every page of your application, that you can use to make data-driven testing decisions.\n\nUI Coverage also seamlessly integrates with your Cypress tests, building on the tests you've already written — no extra instrumentation is required like with code coverage.\n\nTo learn more about UI coverage, please see our [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) guide.\n",
"section": "app",
"anchors": [
"introduction"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 359
},
{
"id": "app/tooling/code-coverage#code-coverage",
"doc_id": "app/tooling/code-coverage",
"heading": "Code Coverage",
"heading_level": 3,
"content_markdown": "### Code Coverage\n\nCode coverage is a metric that helps you understand how much of your application code is covered by your tests. If there are important sections of the application's logic that **were not** executed from the tests, then a new test can be added to ensure that the application logic for these sections is also tested.\n\nComputing the source code lines that were executed during the test is done through **code coverage**. Code coverage requires inserting additional counters into your source code before running it using **instrumentation**. This document will be focused on code coverage and the instrumentation required to set it up.\n",
"section": "app",
"anchors": [
"code-coverage"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 140
},
{
"id": "app/tooling/code-coverage#ui-coverage",
"doc_id": "app/tooling/code-coverage",
"heading": "UI Coverage",
"heading_level": 3,
"content_markdown": "### UI Coverage\n\nUI Coverage is a visual test coverage report based on the interactive elements that make up your application. It highlights areas of missed test coverage directly within every page of your application, that you can use to make data-driven testing decisions.\n\nUI Coverage also seamlessly integrates with your Cypress tests, building on the tests you've already written — no extra instrumentation is required like with code coverage.\n\nTo learn more about UI coverage, please see our [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) guide.\n",
"section": "app",
"anchors": [
"ui-coverage"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 109
},
{
"id": "app/tooling/code-coverage#instrumenting-code",
"doc_id": "app/tooling/code-coverage",
"heading": "Instrumenting code",
"heading_level": 2,
"content_markdown": "## Instrumenting code\n\nInstrumentation takes code that looks like this...\n\nadd.js\n\n```\nfunction add(a, b) { return a + b}module.exports = { add }\n```\n\n...and parses it to find all functions, statements, and branches and then inserts **counters** into the code. For the above code it might look like this:\n\n```\n// this object counts the number of times each// function and each statement is executedconst c = (window.__coverage__ = { // \"f\" counts the number of times each function is called // we only have a single function in the source code thus it starts with [0] f: [0], // \"s\" counts the number of times each statement is called // we have 3 statements and they all start with 0 s: [0, 0, 0],})// the original code + increment statements// uses \"c\" alias to \"window.__coverage__\" object// the first statement defines the function, let's increment itc.s[0]++function add(a, b) { // function is called and then the 2nd statement c.f[0]++ c.s[1]++ return a + b}// 3rd statement is about to be calledc.s[2]++module.exports = { add }\n```\n\nImagine we load the above instrumented source file from our test spec file. Immediately some counters will be incremented!\n\nadd.cy.js\n\n```\nconst { add } = require('./add')// JavaScript engine has parsed and evaluated \"add.js\" source code// which ran some of the increment statements// __coverage__ has now// f: [0] - function \"add\" was NOT executed// s: [1, 0, 1] - first and third counters were incremented// but the statement inside function \"add\" was NOT executed\n```\n\nWe want to make sure every statement and function in the file `add.js` has been executed by our tests at least once. Thus we write a test:\n\nadd.cy.js\n\n```\nconst { add } = require('./add')it('adds numbers', () => { expect(add(2, 3)).to.equal(5)})\n```\n\nWhen the test calls `add(2, 3)`, the counter increments inside the \"add\" function are executed, and the coverage object becomes:\n\n```\n{ // \"f\" keeps count of times each function was called // we only have a single function in the source code // thus it starts with [0] f: [1], // \"s\" keeps count of times each statement was called // we have 3 statements, and they all start with 0 s: [1, 1, 1]}\n```\n\nThis single test has achieved 100% code coverage - every function and every statement has been executed at least once. But, in real world applications, achieving 100% code coverage requires multiple tests.\n\nOnce the tests finish, the coverage object can be serialized and saved to disk so that a human-friendly report can be generated. The collected coverage information can also be sent to external services and can help during pull request reviews.\n\nIf you are unfamiliar with code coverage or want to learn more, take a look at the \"Understanding JavaScript Code Coverage\" blog post [Part 1](https://medium.com/engineering-semantics3/understanding-code-coverage-1074e8fccce0/) and [Part 2](https://medium.com/engineering-semantics3/understanding-javascript-code-coverage-part-2-9aedaa5119e5/).\n\nCypress does not instrument your code - you need to do it yourself. The golden standard for JavaScript code instrumentation is the battle-hardened [Istanbul](https://istanbul.js.org) and, luckily, it plays very nicely with Cypress. You can instrument the code as a build step through one of two ways:\n\n* Using the [nyc](https://github.com/istanbuljs/nyc) module - a command-line interface for the [Istanbul](https://istanbul.js.org) library\n* As part of your code transpilation pipeline using the [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) tool\n\n### Using NYC\n\nTo instrument the application code located in your `src` folder and save it in an `instrumented` folder use the following command:\n\n```\nnpx nyc instrument --compact=false src instrumented\n```\n\nWe are passing the `--compact=false` flag to generate human-friendly output.\n\nThe instrumentation takes your original code like this fragment...\n\nsrc/index.js\n\n```\nconst store = createStore(reducer)render( , document.getElementById('root'))\n```\n\n...and wraps each statement with additional counters that keep track of how many times each source line has been executed by the JavaScript runtime.\n\n```\nconst store = (cov_18hmhptych.s[0]++, createStore(reducer))cov_18hmhptych.s[1]++render( , document.getElementById('root'))\n```\n\nNotice the calls to `cov_18hmhptych.s[0]++` and `cov_18hmhptych.s[1]++` that increment the statement counters. All counters and additional book-keeping information are stored in a single object attached to the browser's `window` object. We can see the counters if we serve the `instrumented` folder instead of `src` and open the application.\n\nIf we drill into the coverage object we can see the statements executed in each file. For example the file `src/index.js` has the following information:\n\nIn green, we highlighted the 4 statements present in that file. The first three statements were each executed once and the last statement was never executed (it probably was inside an `if` statement). By using the application, we can both increment the counters and flip some of the zero counters into positive numbers.\n\n### Using code transpilation pipeline\n\nInstead of using the `npx instrument` command, we can use [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) to instrument the code as part of its transpilation. Add this plugin to the `.babelrc` file.\n\n.babelrc\n\n```\n{ \"presets\": [\"@babel/preset-react\"], \"plugins\": [\"transform-class-properties\", \"istanbul\"]}\n```\n\nWe can now serve the application and get instrumented code without an intermediate folder, but the result is the same instrumented code loaded by the browser, with the same `window.__coverage__` object keeping track of the original statements.\n\nCheck out [`@cypress/code-coverage#examples`](https://github.com/cypress-io/code-coverage#examples) for full example projects showing different code coverage setups.\n\nA really nice feature of both [nyc](https://github.com/istanbuljs/nyc) and [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) is that the source maps are generated automatically, allowing us to collect code coverage information, but also interact with the original, non-instrumented code in the Developer Tools. In the screenshot above, the bundle (green arrow) has coverage counters, but the source mapped files in the green rectangle show the original code.\n\nThe `nyc` and `babel-plugin-istanbul` only instrument the application code and not 3rd party dependencies from `node_modules`.\n",
"section": "app",
"anchors": [
"instrumenting-code"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 1248
},
{
"id": "app/tooling/code-coverage#using-nyc",
"doc_id": "app/tooling/code-coverage",
"heading": "Using NYC",
"heading_level": 3,
"content_markdown": "### Using NYC\n\nTo instrument the application code located in your `src` folder and save it in an `instrumented` folder use the following command:\n\n```\nnpx nyc instrument --compact=false src instrumented\n```\n\nWe are passing the `--compact=false` flag to generate human-friendly output.\n\nThe instrumentation takes your original code like this fragment...\n\nsrc/index.js\n\n```\nconst store = createStore(reducer)render( , document.getElementById('root'))\n```\n\n...and wraps each statement with additional counters that keep track of how many times each source line has been executed by the JavaScript runtime.\n\n```\nconst store = (cov_18hmhptych.s[0]++, createStore(reducer))cov_18hmhptych.s[1]++render( , document.getElementById('root'))\n```\n\nNotice the calls to `cov_18hmhptych.s[0]++` and `cov_18hmhptych.s[1]++` that increment the statement counters. All counters and additional book-keeping information are stored in a single object attached to the browser's `window` object. We can see the counters if we serve the `instrumented` folder instead of `src` and open the application.\n\nIf we drill into the coverage object we can see the statements executed in each file. For example the file `src/index.js` has the following information:\n\nIn green, we highlighted the 4 statements present in that file. The first three statements were each executed once and the last statement was never executed (it probably was inside an `if` statement). By using the application, we can both increment the counters and flip some of the zero counters into positive numbers.\n",
"section": "app",
"anchors": [
"using-nyc"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 303
},
{
"id": "app/tooling/code-coverage#using-code-transpilation-pipeline",
"doc_id": "app/tooling/code-coverage",
"heading": "Using code transpilation pipeline",
"heading_level": 3,
"content_markdown": "### Using code transpilation pipeline\n\nInstead of using the `npx instrument` command, we can use [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) to instrument the code as part of its transpilation. Add this plugin to the `.babelrc` file.\n\n.babelrc\n\n```\n{ \"presets\": [\"@babel/preset-react\"], \"plugins\": [\"transform-class-properties\", \"istanbul\"]}\n```\n\nWe can now serve the application and get instrumented code without an intermediate folder, but the result is the same instrumented code loaded by the browser, with the same `window.__coverage__` object keeping track of the original statements.\n\nCheck out [`@cypress/code-coverage#examples`](https://github.com/cypress-io/code-coverage#examples) for full example projects showing different code coverage setups.\n\nA really nice feature of both [nyc](https://github.com/istanbuljs/nyc) and [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) is that the source maps are generated automatically, allowing us to collect code coverage information, but also interact with the original, non-instrumented code in the Developer Tools. In the screenshot above, the bundle (green arrow) has coverage counters, but the source mapped files in the green rectangle show the original code.\n\nThe `nyc` and `babel-plugin-istanbul` only instrument the application code and not 3rd party dependencies from `node_modules`.\n",
"section": "app",
"anchors": [
"using-code-transpilation-pipeline"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 221
},
{
"id": "app/tooling/code-coverage#e2e-code-coverage",
"doc_id": "app/tooling/code-coverage",
"heading": "E2E code coverage",
"heading_level": 2,
"content_markdown": "## E2E code coverage\n\nTo handle code coverage collected during each test, there is a [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) Cypress plugin. It merges coverage from each test and saves the combined result. It also calls `nyc` (its peer dependency) to generate static HTML reports for human consumption.\n\n### Install the plugin\n\nPlease consult the [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) documentation for up-to-date installation instructions.\n\n```\nnpm install @cypress/code-coverage --save-dev\n```\n\nThen add the code below to the [supportFile](/llm/markdown/app/references/configuration.md#e2e) and [setupNodeEvents](/llm/markdown/app/plugins/plugins-guide.md#Using-a-plugin) function.\n\n```\n// cypress/support/e2e.jsimport '@cypress/code-coverage/support'\n```\n\n* cypress.config.js\n* cypress.config.ts\n\n```\nconst { defineConfig } = require('cypress')module.exports = defineConfig({ // setupNodeEvents can be defined in either // the e2e or component configuration e2e: { setupNodeEvents(on, config) { require('@cypress/code-coverage/task')(on, config) // include any other plugin code... // It's IMPORTANT to return the config object // with any changed environment variables return config }, },})\n```\n\n```\nimport { defineConfig } from 'cypress'export default defineConfig({ // setupNodeEvents can be defined in either // the e2e or component configuration e2e: { setupNodeEvents(on, config) { require('@cypress/code-coverage/task')(on, config) // include any other plugin code... // It's IMPORTANT to return the config object // with any changed environment variables return config }, },})\n```\n\nWhen you run the Cypress tests now, you should see a few commands after the tests finish. We have highlighted these commands using a green rectangle below.\n\nAfter the tests complete, the final code coverage is saved to a `.nyc_output` folder. It is a JSON file from which we can generate a report in a variety of formats. The [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) plugin generates the HTML report automatically - you can open the `coverage/index.html` page locally after the tests finish. You can also call `nyc report` to generate other reports, for example, sending the coverage information to 3rd party services.\n\n### See code coverage summary\n\nTo see the summary of the code coverage after tests run, run the command below.\n\n```\nnpx nyc report --reporter=text-summary========= Coverage summary =======Statements : 76.3% ( 103/135 )Branches : 65.31% ( 32/49 )Functions : 64% ( 32/50 )Lines : 81.42% ( 92/113 )==================================\n```\n\n**Tip:** store the `coverage` folder as a build artifact on your continuous integration server. Because the report is a static HTML page, some CIs can show it right from their web applications. The screenshot below shows the coverage report stored on CircleCI. Clicking on `index.html` shows the report right in the browser.\n",
"section": "app",
"anchors": [
"e2e-code-coverage"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 520
},
{
"id": "app/tooling/code-coverage#install-the-plugin",
"doc_id": "app/tooling/code-coverage",
"heading": "Install the plugin",
"heading_level": 3,
"content_markdown": "### Install the plugin\n\nPlease consult the [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) documentation for up-to-date installation instructions.\n\n```\nnpm install @cypress/code-coverage --save-dev\n```\n\nThen add the code below to the [supportFile](/llm/markdown/app/references/configuration.md#e2e) and [setupNodeEvents](/llm/markdown/app/plugins/plugins-guide.md#Using-a-plugin) function.\n\n```\n// cypress/support/e2e.jsimport '@cypress/code-coverage/support'\n```\n\n* cypress.config.js\n* cypress.config.ts\n\n```\nconst { defineConfig } = require('cypress')module.exports = defineConfig({ // setupNodeEvents can be defined in either // the e2e or component configuration e2e: { setupNodeEvents(on, config) { require('@cypress/code-coverage/task')(on, config) // include any other plugin code... // It's IMPORTANT to return the config object // with any changed environment variables return config }, },})\n```\n\n```\nimport { defineConfig } from 'cypress'export default defineConfig({ // setupNodeEvents can be defined in either // the e2e or component configuration e2e: { setupNodeEvents(on, config) { require('@cypress/code-coverage/task')(on, config) // include any other plugin code... // It's IMPORTANT to return the config object // with any changed environment variables return config }, },})\n```\n\nWhen you run the Cypress tests now, you should see a few commands after the tests finish. We have highlighted these commands using a green rectangle below.\n\nAfter the tests complete, the final code coverage is saved to a `.nyc_output` folder. It is a JSON file from which we can generate a report in a variety of formats. The [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) plugin generates the HTML report automatically - you can open the `coverage/index.html` page locally after the tests finish. You can also call `nyc report` to generate other reports, for example, sending the coverage information to 3rd party services.\n",
"section": "app",
"anchors": [
"install-the-plugin"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 327
},
{
"id": "app/tooling/code-coverage#see-code-coverage-summary",
"doc_id": "app/tooling/code-coverage",
"heading": "See code coverage summary",
"heading_level": 3,
"content_markdown": "### See code coverage summary\n\nTo see the summary of the code coverage after tests run, run the command below.\n\n```\nnpx nyc report --reporter=text-summary========= Coverage summary =======Statements : 76.3% ( 103/135 )Branches : 65.31% ( 32/49 )Functions : 64% ( 32/50 )Lines : 81.42% ( 92/113 )==================================\n```\n\n**Tip:** store the `coverage` folder as a build artifact on your continuous integration server. Because the report is a static HTML page, some CIs can show it right from their web applications. The screenshot below shows the coverage report stored on CircleCI. Clicking on `index.html` shows the report right in the browser.\n",
"section": "app",
"anchors": [
"see-code-coverage-summary"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 135
},
{
"id": "app/tooling/code-coverage#code-coverage-as-a-guide",
"doc_id": "app/tooling/code-coverage",
"heading": "Code coverage as a guide",
"heading_level": 2,
"content_markdown": "## Code coverage as a guide\n\nEven a single test can cover a lot of the application code. For example, let's run the following test that adds a few items, then marks one of them as completed.\n\n* End-to-End Test\n* Component Test\n\n```\nit('adds and completes todos', () => { cy.visit('/') cy.get('.new-todo').type('write code{enter}') cy.get('.new-todo').type('write tests{enter}') cy.get('.new-todo').type('deploy{enter}') cy.get('.todo').should('have.length', 3) cy.get('.todo').first().find('.toggle').check() cy.get('.todo').first().should('have.class', 'completed')})\n```\n\n```\nit('adds and completes todos', () => { cy.mount() cy.get('.new-todo').type('write code{enter}') cy.get('.new-todo').type('write tests{enter}') cy.get('.new-todo').type('deploy{enter}') cy.get('.todo').should('have.length', 3) cy.get('.todo').first().find('.toggle').check() cy.get('.todo').first().should('have.class', 'completed')})\n```\n\nAfter running the test and opening the HTML report, we see 76% code coverage in our application.\n\nEven better, we can drill down into the individual source files to see what code we missed. In our example application, the main state logic is in the `src/reducers/todos.js` file. Let's see the code coverage in this file:\n\nNotice how the **ADD\\_TODO** action was executed 3 times - because our test has added 3 todo items, and the **COMPLETE\\_TODO** action was executed just once - because our test has marked 1 todo item as completed.\n\nThe source lines not covered, marked in yellow (the switch cases the test missed) and red (regular statements) are a great guide for writing more end-to-end tests. We need tests that delete todo items, edit them, mark all of them as completed at once and clear completed items. When we cover every switch statement in `src/reducers/todos.js` we probably will achieve close to 100% code coverage. Even more importantly, we will cover the main features of the application the user is expected to use.\n\nWe can write more E2E tests.\n\nThe produced HTML report shows 99% code coverage\n\nEvery source file but one is covered at 100%. We can have great confidence in our application, and safely refactor the code knowing that we have a robust set of end-to-end tests.\n\nIf possible, we advise implementing [visual testing](/llm/markdown/app/tooling/visual-testing.md) in addition to Cypress functional tests to avoid CSS and visual regressions.\n",
"section": "app",
"anchors": [
"code-coverage-as-a-guide"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 432
},
{
"id": "app/tooling/code-coverage#combining-code-coverage-from-parallel-tests",
"doc_id": "app/tooling/code-coverage",
"heading": "Combining code coverage from parallel tests",
"heading_level": 2,
"content_markdown": "## Combining code coverage from parallel tests\n\nIf you execute Cypress tests in [parallel](/llm/markdown/cloud/features/smart-orchestration/parallelization.md), each machine ends up with a code coverage report that only shows a portion of the code exercised. Typically an external code coverage service would merge such partial reports for you. If you do want to merge the reports yourself:\n\n* on every machine running Cypress tests, copy the produced code coverage report into a common folder under a unique name to avoid overwriting it\n* after all E2E tests finish, combine the reports yourself using the `nyc merge` command\n\nYou can find an example of merging partial reports in our [cypress-io/cypress-example-conduit-app](https://github.com/cypress-io/cypress-example-conduit-app)\n",
"section": "app",
"anchors": [
"combining-code-coverage-from-parallel-tests"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 141
},
{
"id": "app/tooling/code-coverage#e2e-and-unit-code-coverage",
"doc_id": "app/tooling/code-coverage",
"heading": "E2E and unit code coverage",
"heading_level": 2,
"content_markdown": "## E2E and unit code coverage\n\nLet's look at the one file that has a \"missed\" line. It is the `src/selectors/index.js` file shown below.\n\nThe source line not covered by the end-to-end tests shows an edge case NOT reachable from the UI. Yet this switch case is definitely worth testing - at least to avoid accidentally changing its behavior during future refactoring.\n\nWe can directly test this piece of code by importing the `getVisibleTodos` function from the Cypress spec file. In essence we are using Cypress as a unit testing tool (find more unit testing recipes [here](https://github.com/cypress-io/cypress-example-recipes#unit-testing)).\n\nHere is our test to confirm that the error is thrown.\n\n```\n// cypress/e2e/selectors.cy.jsimport { getVisibleTodos } from '../../src/selectors'describe('getVisibleTodos', () => { it('throws an error for unknown visibility filter', () => { expect(() => { getVisibleTodos({ todos: [], visibilityFilter: 'unknown-filter', }) }).to.throw() })})\n```\n\nThe test passes, even if there is no web application visited.\n\nPreviously we instrumented the application code (either using a build step or inserting a plugin into the Babel pipeline). In the example above, we are NOT loading an application, instead we are only running the test files by themselves.\n\nIf we want to collect the code coverage from the unit tests, we need to instrument the source code of _our spec files_. The simplest way to do this is to use the same `.babelrc` with [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) and tell the Cypress built-in bundler to use `.babelrc` when bundling specs. One can use the [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) plugin again to do this by adding the code below to the [setupNodeEvents](/llm/markdown/app/plugins/plugins-guide.md#Using-a-plugin) function.\n\n* cypress.config.js\n* cypress.config.ts\n\n```\nconst { defineConfig } = require('cypress')module.exports = defineConfig({ // setupNodeEvents can be defined in either // the e2e or component configuration e2e: { setupNodeEvents(on, config) { require('@cypress/code-coverage/task')(on, config) // tell Cypress to use .babelrc file // and instrument the specs files // only the extra application files will be instrumented // not the spec files themselves on('file:preprocessor', require('@cypress/code-coverage/use-babelrc')) return config }, },})\n```\n\n```\nimport { defineConfig } from 'cypress'export default defineConfig({ // setupNodeEvents can be defined in either // the e2e or component configuration e2e: { setupNodeEvents(on, config) { require('@cypress/code-coverage/task')(on, config) // tell Cypress to use .babelrc file // and instrument the specs files // only the extra application files will be instrumented // not the spec files themselves on('file:preprocessor', require('@cypress/code-coverage/use-babelrc')) return config }, },})\n```\n\nFor reference, the `.babelrc` file is shared between the example application and the spec files, thus Cypress tests are transpiled the same way the application code is transpiled.\n\n```\n{ \"presets\": [\"@babel/preset-react\"], \"plugins\": [\"transform-class-properties\", \"istanbul\"]}\n```\n\nWhen we run Cypress with [`babel-plugin-istanbul`](https://github.com/istanbuljs/babel-plugin-istanbul) included and inspect the `window.__coverage__` object in the **spec iframe**, we should see the coverage information for the application source files.\n\nThe code coverage information in unit tests and end-to-end tests has the same format; the [`@cypress/code-coverage`](https://github.com/cypress-io/code-coverage) plugin automatically grabs both and saves the combined report. Thus we can see the code coverage from the `cypress/e2e/selectors.cy.js` file after running the test.\n\nOur unit test is hitting the line we could not reach from the end-to-end tests, and if we execute all spec files - we will get 100% code coverage.\n",
"section": "app",
"anchors": [
"e2e-and-unit-code-coverage"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 697
},
{
"id": "app/tooling/code-coverage#full-stack-code-coverage",
"doc_id": "app/tooling/code-coverage",
"heading": "Full stack code coverage",
"heading_level": 2,
"content_markdown": "## Full stack code coverage\n\nA complex application might have a Node back end with its own complex logic. From the front end web application, the calls to the API go through layers of code. It would be nice to track what back end code has been exercised during Cypress end-to-end tests.\n\nAre our end-to-end tests that are so effective at covering the web application code also covering the back end server code?\n\n**Long story short: yes.** You can collect the code coverage from the back end, and let the `@cypress/code-coverage` plugin merge it with the front end coverage, creating a single full stack report.\n\nThe full source code for this section can be found in the [cypress-io/cypress-example-conduit-app](https://github.com/cypress-io/cypress-example-conduit-app) repository.\n\nYou can run your Node server and instrument it using nyc on the fly. Instead of the \"normal\" server start command, you can run the command `npm run start:coverage` defined in the `package.json` like this:\n\n```\n{ \"scripts\": { \"start\": \"node server\", \"start:coverage\": \"nyc --silent node server\" }}\n```\n\nIn your server, insert another middleware from `@cypress/code-coverage`. If you use an Express server, include `middleware/express`:\n\n```\nconst express = require('express')const app = express()require('@cypress/code-coverage/middleware/express')(app)\n```\n\nIf your server uses hapi, include `middleware/hapi`\n\n```\nif (global.__coverage__) { require('@cypress/code-coverage/middleware/hapi')(server)}\n```\n\n**Tip:** you can conditionally register the endpoint only if there is a global code coverage object, and you can [exclude the middleware code from the coverage numbers](https://github.com/gotwarlost/istanbul/blob/master/ignoring-code-for-coverage.md):\n\n```\n/* istanbul ignore next */if (global.__coverage__) { require('@cypress/code-coverage/middleware/hapi')(server)}\n```\n\nFor any other server type, define a `GET /__coverage__` endpoint and return the `global.__coverage__` object.\n\n```\nif (global.__coverage__) { // handle \"GET __coverage__\" requests onRequest = (response) => { response.sendJSON({ coverage: global.__coverage__ }) }}\n```\n\nIn order for the `@cypress/code-coverage` plugin to know that it should request the back end coverage, add the new endpoint to the Cypress configuration environment settings under `env.codeCoverage.url` key. For example, if the application back end is running at port 3000 and we are using the default \"GET /**coverage**\" endpoint, set the following:\n\n* cypress.config.js\n* cypress.config.ts\n\n```\nconst { defineConfig } = require('cypress')module.exports = defineConfig({ env: { codeCoverage: { url: 'http://localhost:3000/__coverage__', }, },})\n```\n\n```\nimport { defineConfig } from 'cypress'export default defineConfig({ env: { codeCoverage: { url: 'http://localhost:3000/__coverage__', }, },})\n```\n\nFrom now on, the front end code coverage collected during end-to-end tests will be merged with the code coverage from the instrumented back end code and saved in a single report. Here is an example report from the [cypress-io/cypress-example-conduit-app](https://github.com/cypress-io/cypress-example-conduit-app) example:\n\nYou can explore the above combined full stack coverage report at the [coveralls.io/github/cypress-io/cypress-example-conduit-app](https://coveralls.io/github/cypress-io/cypress-example-conduit-app) dashboard. You can also find full stack code coverage in our [RealWorld App](https://github.com/cypress-io/cypress-realworld-app).\n\nEven if you only want to measure the back end code coverage Cypress can help.\n",
"section": "app",
"anchors": [
"full-stack-code-coverage"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 603
},
{
"id": "app/tooling/code-coverage#videos",
"doc_id": "app/tooling/code-coverage",
"heading": "Videos",
"heading_level": 2,
"content_markdown": "## Videos\n\nThere is a series of videos we have recorded showing code coverage in Cypress\n\n### How to instrument react-scripts web application for code coverage\n\n### Get code coverage reports from Cypress tests\n\n### Excluding code from code coverage reports\n\n### Check code coverage robustly using 3rd party tool\n\n### Adding code coverage badge to your project\n\n### Show code coverage in commit status check\n\n### Checking code coverage on pull request\n",
"section": "app",
"anchors": [
"videos"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 97
},
{
"id": "app/tooling/code-coverage#examples",
"doc_id": "app/tooling/code-coverage",
"heading": "Examples",
"heading_level": 2,
"content_markdown": "## Examples\n\nYou can find full examples showing different code coverage setups in the following repositories:\n\n* [cypress-io/cypress-realworld-app](https://github.com/cypress-io/cypress-realworld-app) or RWA is a full stack example application that demonstrates **best practices and scalable strategies with Cypress in practical and realistic scenarios**. The RWA achieves full code coverage with end-to-end tests [across multiple browsers](/llm/markdown/app/guides/cross-browser-testing.md) and [device sizes](/llm/markdown/api/commands/viewport.md).\n* [lluia/cypress-typescript-coverage-example](https://github.com/lluia/cypress-typescript-coverage-example) shows coverage for a React App that uses TypeScript.\n* [ericorruption/cypress-code-coverage-typescript-webpack-ts-loader](https://github.com/ericorruption/cypress-code-coverage-typescript-webpack-ts-loader) shows how to collect coverage for a TypeScript + webpack project using `ts-loader` instead of `babel-loader`.\n\nFind the full list of examples linked in [cypress-io/code-coverage#external-examples](https://github.com/cypress-io/code-coverage#external-examples).\n",
"section": "app",
"anchors": [
"examples"
],
"path": "/llm/json/chunked/app/tooling/code-coverage.json",
"token_estimate": 124
}
]
}