--- id: ui-coverage/faq title: Cypress UI Coverage FAQ description: >- Answers to common questions about Cypress UI Coverage: how it differs from code coverage, coverage scores, closing gaps, configuration, and the Results API. section: ui-coverage source_path: docs/ui-coverage/faq.mdx version: 29f95bf8bb06f320986f3749f5bf09a35a409eab updated_at: '2026-09-04T10:49:54.630Z' --- # Cypress UI Coverage FAQ **UI Coverage** turns your runs into a visual map of the interactive elements your tests exercise and the ones they miss, with no code changes or instrumentation. [Schedule a demo](https://www.cypress.io/ui-coverage?utm_medium=premium-solution-tip&utm_source=docs.cypress.io&utm_content=Schedule%20a%20demo). ## General ### What is UI Coverage? [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) is a Cypress Cloud feature that shows you which interactive elements of your application your tests actually exercise. Every recorded run produces a visual report of tested and untested elements across all of your application's [views](/llm/markdown/ui-coverage/core-concepts/views.md), along with a coverage score you can track over time. ### Do I need to install anything to use UI Coverage? No. UI Coverage requires no code changes or instrumentation. Reports are generated from [Test Replay](/llm/markdown/cloud/features/test-replay.md) data, so any run recorded to Cypress Cloud with Test Replay on Cypress v13 or later is ready to use. See [setup](/llm/markdown/ui-coverage/get-started/setup.md) for details. ### How is the UI Coverage score calculated? The Cypress UI Coverage score compares the number of tested interactive elements to the total number of interactive elements in your application. Three rules determine what goes into that comparison: * **[Grouped elements](/llm/markdown/ui-coverage/core-concepts/element-grouping.md) count as a single unit.** The group counts once toward the total, and an interaction with any element in the group marks the whole group as tested. * **Links share the same total.** Each distinct link destination counts as one unit, and counts as tested when a test either interacts with the link or visits its destination. * **Only [visible](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Visibility) elements count.** An element that was never visible in any snapshot is excluded from both the tested and total counts, so it neither raises nor lowers your score. ### How do I get started with UI Coverage? Record a run to Cypress Cloud with [Test Replay](/llm/markdown/cloud/features/test-replay.md) enabled on Cypress v13 or later, then open its **UI Coverage** tab. A report is generated automatically for every recorded run, with no code changes, plugin, or instrumentation. From there you can read your coverage score, drill into your lowest-scoring [views](/llm/markdown/ui-coverage/core-concepts/views.md), and optionally tune the report with [App Quality configuration](/llm/markdown/ui-coverage/configuration/overview.md). The [Get Started guide](/llm/markdown/ui-coverage/get-started/setup.md) walks through the whole path. ### What do I need to use UI Coverage? Three things: a Cypress project recording to [Cypress Cloud](/llm/markdown/cloud/get-started/introduction.md), [Test Replay](/llm/markdown/cloud/features/test-replay.md) enabled for the run (reports are built entirely from Test Replay data), and Cypress v13 or later. UI Coverage isn't included in standard Cloud plans, so you'll also need it enabled for your organization, which you can do with a [free trial](/llm/markdown/ui-coverage/get-started/setup.md#Step-1-Start-your-UI-Coverage-trial). No test changes, plugins, or code instrumentation are required. ### Is UI Coverage included in my Cypress Cloud plan? UI Coverage isn't part of the standard Cypress Cloud plans; it's enabled separately for your organization. You can turn it on for your projects with a [free trial](/llm/markdown/ui-coverage/get-started/setup.md#Step-1-Start-your-UI-Coverage-trial), which uses your existing recorded runs so you can see your coverage gaps before committing. To find out what's available for your account, start a trial or talk to your Cypress point-of-contact. ### How soon after a run can I see its UI Coverage report? The report is generated in Cypress Cloud after the run finishes recording, so it's ready shortly after your run completes rather than during the run itself. Nothing in your Cypress pipeline waits on or fails because of UI Coverage; open the run's **UI Coverage** tab once processing finishes to read it. ### Does UI Coverage work with Cypress component testing? Yes. UI Coverage reports on both end-to-end and component runs. In component testing, each spec file becomes a single [view](/llm/markdown/ui-coverage/core-concepts/views.md) named by the spec's file path, and every component mounted in that spec is grouped into it. Everything else, including the coverage score, untested elements, and configuration, works the same way as it does for end-to-end runs. ### Is UI Coverage the same as code coverage? No. Code coverage measures which lines, branches, or functions of your source code ran during a test. UI Coverage measures your application the way a user meets it: the share of _interactive elements_ (buttons, inputs, links, and controls) your tests actually exercised. The two answer different questions. A line of code can back many controls, and simply importing a module can mark it "covered" without a user ever touching the interface, so high code coverage can still hide untested buttons and pages. UI Coverage closes that gap by reporting on the rendered DOM, and it needs no instrumentation or build tooling to do it. The two are complementary, and many teams track both. ### Does UI Coverage affect how my tests run or slow them down? No. UI Coverage adds nothing to test execution. Reports are generated in Cypress Cloud _after_ a run finishes recording, from the [Test Replay](/llm/markdown/cloud/features/test-replay.md) data your run already captured, so there's no extra work during the run and nothing in your Cypress pipeline waits on or fails because of UI Coverage. ### Does UI Coverage work with my framework, and do I have to change my code? Yes, and no. UI Coverage analyzes the rendered DOM captured by [Test Replay](/llm/markdown/cloud/features/test-replay.md), not your source code, so it's framework-agnostic. React, Vue, Angular, Svelte, server-rendered HTML, or anything else that produces a DOM works the same way. You don't change your application code, add a plugin, or write any configuration to get a report; configuration is opt-in and comes later, only when you want to sharpen the results. ### What's the difference between UI Coverage and Cypress Accessibility? Both are Cypress Cloud [App Quality](/llm/markdown/ui-coverage/configuration/overview.md) features built on the same [Test Replay](/llm/markdown/cloud/features/test-replay.md) data, and both need no code changes. They measure different things: UI Coverage tells you _how much_ of your interactive UI your tests exercise (a coverage score plus untested elements and links), while [Cypress Accessibility](/llm/markdown/accessibility/get-started/introduction.md) tells you _whether_ the UI your tests render has accessibility violations. They share configuration properties like [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) and [`elementFilters`](/llm/markdown/ui-coverage/configuration/elementfilters.md), which you can scope to one product or the other. See [Configuration scope](/llm/markdown/ui-coverage/configuration/overview.md#Configuration-scope). ### Can I use UI Coverage with AI agents? Yes. Because every report is structured data about which interactive elements your tests exercised, a compatible AI agent can read it and act on it through the [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md). An agent can pull a run's coverage score and untested elements, summarize the biggest gaps, correlate a coverage drop with specific specs, and draft targeted tests to close the gaps, while your team keeps ownership of what "enough coverage" means for each area. See [Use AI agents with UI Coverage](/llm/markdown/ui-coverage/work-with-ai-agents.md) for example prompts and how to tune reports for clearer agent signal. ## Finding coverage gaps ### How do I find which parts of my UI aren't tested? Record a run to Cypress Cloud with [Test Replay](/llm/markdown/cloud/features/test-replay.md) enabled, then open its **UI Coverage** tab. Every recorded run produces a report automatically, with no code changes. The report ranks your application's [views](/llm/markdown/ui-coverage/core-concepts/views.md) by coverage score, lists the untested interactive elements on each one, and flags the pages your tests never visited as [untested links](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links). The [Identify coverage gaps](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md) guide walks through the full workflow step by step. ### Where should I start if my UI Coverage score is low? In Cypress Cloud, start with your lowest-scoring [views](/llm/markdown/ui-coverage/core-concepts/views.md), weighed against how critical each one is to your users, since a checkout or signup view at 40% is more urgent than a settings page at the same score. Before writing tests, rule out noise: third-party widgets counted as untested elements (exclude them with [`elementFilters`](/llm/markdown/ui-coverage/configuration/elementfilters.md)) and links to pages you'll never test (exclude them with [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md)) both lower a score without pointing to a real gap. See [Why is my UI Coverage score lower than I expect?](#Why-is-my-UI-Coverage-score-lower-than-I-expect) and [Identify coverage gaps](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md). ### In Cypress UI Coverage, what's the difference between an untested element, an untested link, and an untested view? They describe three different gaps. An **untested element** is an interactive element (a button, input, or control) on a page your tests opened that no recognized command interacted with. An **untested link** is an `` element whose destination URL was never visited during the run. An **untested view** is a page discovered from those untested links that no test ever opened, so it has no coverage at all. Untested elements and untested links both count against your score; untested views surface pages that need a test to reach them. See [Interactivity](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links) and [Views](/llm/markdown/ui-coverage/core-concepts/views.md). ### How do I find pages my tests never visit? Use the **Untested links** section of the UI Coverage report. It lists links whose destinations your Cypress tests never opened during the run, and expanding one shows a **Referrers** tab (the views that link to the page) and a **URLs** tab (the concrete destinations, grouped for dynamic routes like `/orders/*`). Because a page with no view can still be linked from a tested page, this is how UI Coverage surfaces flows your suite is missing entirely. Add navigation to reach them, as shown in [Address coverage gaps](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md#Cover-untested-links). ## Closing coverage gaps ### How do I close a coverage gap in Cypress UI Coverage? Add a test that exercises the untested element the report surfaces. First [confirm each gap is worth testing](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md#Step-1-Confirm-the-gap-is-real), starting with the ones that carry the most risk, such as controls on your checkout or login views, then close each one either with [Test Generation](#What-is-Test-Generation-in-Cypress-UI-Coverage) or by writing a targeted test yourself. An element moves from untested to tested once a [recognized interaction command](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Interaction-Commands) targets it. See [Address coverage gaps](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md) for the full workflow. ### What is Test Generation in Cypress UI Coverage? Test Generation uses AI to draft a Cypress test for an untested interactive element, following the setup and conventions your existing specs already use. Select an untested element in the report, click **Generate test code**, and choose a spec from the list of specs where that element appears. Cypress generates a test that reproduces the setup to reach the element (reusing your custom commands), performs an appropriate interaction, and leaves a `TODO` marking where to add your assertions. Treat it as a reviewed starting point, then add the assertions that prove the flow works. See [Generate tests from UI Coverage reports](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md#Generate-tests-from-UI-Coverage-reports). ### Can Cypress UI Coverage write tests for me? Yes, through [Test Generation](#What-is-Test-Generation-in-Cypress-UI-Coverage). It produces a working test that exercises the untested element so UI Coverage counts it, built from the same patterns and custom commands your existing specs use. It's a starting point rather than a finished test: you copy the snippet into the suggested spec and add the assertions that verify behavior. Test Generation is part of UI Coverage and isn't available on standard Cloud plans; it also requires a report processed on or after November 21, 2024, project membership, and that AI capabilities are enabled for your organization. ### How do I test a page that my Cypress suite never visits? Add navigation to the page so it renders during a run. Pages your tests link to but never visit appear in the [**Untested links**](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links) section, and UI Coverage can't report on any element they contain until a test goes there. Add a `cy.visit()` (or a click that navigates to it), which turns the untested link green and creates a [view](/llm/markdown/ui-coverage/core-concepts/views.md) for the page that then surfaces its own untested elements. Test Generation doesn't apply to untested links; it targets interactive elements, so navigation is the fix here. ### How do I cover an element that only appears after login or a click? Drive the interaction that puts the UI into that state before interacting with the element. A control inside a collapsed menu, a modal, or a section that only renders after signing in won't be exercised until your test reveals it, so click the toggle or run your `cy.login()` command first, then interact with the now-visible element. Each new state your tests reach adds its snapshot to the Cypress UI Coverage report, so previously hidden elements start appearing as tested. ### Which coverage gaps should I fix first in Cypress UI Coverage? Prioritize by risk, not by count. Start with the views behind your highest-value flows (checkout, login, account settings), then untested links, which often hide an entire flow rather than a single control, and weight the list by real usage so a heavily used page with low coverage is closed before a lightly used one. See [Confirm the gap is real](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md#Step-1-Confirm-the-gap-is-real) and [Start with your lowest-scoring views](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md#Step-3-Start-with-your-lowest-scoring-views). ### Why did closing one coverage gap reveal more untested elements? Because visiting a page or reaching a new state exposes controls Cypress UI Coverage had never seen. When a test navigates to a previously [untested link](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links), UI Coverage creates a [view](/llm/markdown/ui-coverage/core-concepts/views.md) for that page and lists every interactive element on it, most of which start untested. This is expected, and it's why closing gaps is a loop: each pass surfaces the next set of elements to prioritize. ## Comparing reports across runs ### How do I compare UI Coverage reports between two runs? You have two routes. In [Branch Review](/llm/markdown/cloud/features/branch-review.md) in Cypress Cloud, pick a **base run** and a **changed run** from the dropdowns (or let Cypress select them automatically when the changed run is tied to a pull request) and it shows only what changed between them: the elements and pages that became untested, the gaps the change closed, and everything new it added. If you'd rather stay in your editor, the [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) lets an AI agent pull both runs' coverage and report the diff for you. Both compare any two runs already recorded to Cypress Cloud. See [Compare reports](/llm/markdown/ui-coverage/guides/compare-reports.md) for the full workflow with each. ### What's the difference between the base run and the changed run in Branch Review? The **changed run** is the focal point of the comparison, so everything you see, including every count and drilldown, is data from the changed run. The **base run** is the reference it's measured against. In a pull request, the changed run is your feature branch and the base run is the branch you're merging into, so the diff shows exactly what your change did to coverage. ### How do I tell whether a pull request reduced my UI Coverage? Open the pull request's run in [Branch Review](/llm/markdown/cloud/features/branch-review.md) and read the coverage-score change at the top: it's labeled a **coverage improvement** when the score rose and a **reduction in coverage** when it fell. A reduction points you to the **New untested elements** and **New untested links** sections, which list the specific controls and pages the change left untested. You can also ask an AI agent to report the same diff from your editor with the [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md). See [Compare reports](/llm/markdown/ui-coverage/guides/compare-reports.md) and [Block pull requests](/llm/markdown/ui-coverage/guides/block-pull-requests.md) to fail CI automatically when coverage drops. ### What's the difference between a new untested element and a resolved untested element in UI Coverage? A **new untested element** is untested in the changed run and was either tested in the base run or didn't exist there, so it represents coverage that regressed. A **resolved untested element** was untested in the base run and is now tested, so it's proof a gap was closed. Branch Review shows both, along with a link to the elements untested in both runs. Untested links are broken out the same way. A new untested element appears either because the test code stopped interacting with it, or because an application change added it without a test. See [Compare reports](/llm/markdown/ui-coverage/guides/compare-reports.md#Step-3-Review-new-untested-elements-and-links). ### Why does a page or element appear as "new" when I compare two UI Coverage runs? Usually because a dynamic value in the URL or an element attribute isn't being matched consistently across runs. A URL slug that isn't grouped into a stable [view](/llm/markdown/ui-coverage/core-concepts/views.md) can appear as a new page, and an identifier carrying a per-build hash can make one element show as both resolved and new. Group dynamic URLs with [`views`](/llm/markdown/ui-coverage/configuration/views.md) and exclude unstable identifiers with [`attributeFilters`](/llm/markdown/ui-coverage/configuration/attributefilters.md), then regenerate the run. See [Stabilize the comparison](/llm/markdown/ui-coverage/guides/compare-reports.md#Step-6-Stabilize-the-comparison-with-configuration). ### How do I get an accurate Cypress UI Coverage comparison between two runs? For an accurate Cypress UI Coverage comparison, compare passing runs that ran similar tests on the same content, so each run visited roughly the same pages and completed the same workflows; then any difference in the diff reflects the change in the newer run. This is what you get out of the box when comparing a pull-request branch against its base. Comparing runs from different points in time is still valid, as long as you account for the other sources of difference as you read the results. To see unified changes for your whole suite, group all of a commit's tests under a single Cypress run per report. This guidance applies whether you compare in Branch Review or with the [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md), since both read the same recorded runs. See [Compare reports](/llm/markdown/ui-coverage/guides/compare-reports.md) and [Branch Review best practices](/llm/markdown/cloud/features/branch-review.md#Best-Practices). ### Do I need to rerun my tests to compare two UI Coverage reports? No. Branch Review compares two runs that are already recorded to Cypress Cloud, so any two recorded runs can be compared without re-running anything. The same is true when comparing with the [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md), which reads those same recorded runs. If you only changed configuration and want to compare the effect, regenerate a past run from its **Properties** tab instead of recording again. See [Compare reports](/llm/markdown/ui-coverage/guides/compare-reports.md). ### Can I compare UI Coverage reports with an AI agent or the Cypress Cloud MCP? Yes. The [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) lets a compatible AI agent pull the UI Coverage for two runs and report the diff from your editor, using `cypress_get_runs` to find the runs and `cypress_get_ui_coverage_report`, `cypress_get_ui_coverage_views`, and `cypress_get_ui_coverage_elements` to read each run's coverage. There's no single compare tool; the agent assembles the diff and can then draft a test to close a regression. It's a peer to Branch Review, which remains the place to see full-page DOM snapshots of what changed. See [Compare reports with the Cypress Cloud MCP](/llm/markdown/ui-coverage/guides/compare-reports.md#Compare-reports-with-the-Cypress-Cloud-MCP). ## Monitoring coverage over time ### How do I track my UI Coverage score over time? Record runs on a regular cadence so there's always something to compare, then watch the direction the score moves rather than a single number. Record a run for every pull request to catch regressions before they merge, and add a scheduled job (such as a nightly CI cron) that records against a stable environment for a consistent baseline that isn't affected by which files a given pull request touched. From there, [Branch Review](/llm/markdown/cloud/features/branch-review.md) diffs any two runs and the [Results API](/llm/markdown/ui-coverage/results-api.md) enforces the trend in CI. See [Monitor changes](/llm/markdown/ui-coverage/guides/monitor-changes.md) for the full workflow. ### How do I get notified when my UI Coverage changes? Connect [Slack](/llm/markdown/cloud/integrations/slack.md) or [Microsoft Teams](/llm/markdown/cloud/integrations/microsoft-teams.md) to your project so your team is alerted whenever a run finishes, with Slack surfacing UI Coverage results directly. To put the change in front of reviewers, connect a version control integration ([GitHub](/llm/markdown/cloud/integrations/github.md#Pull-request-comments), [GitLab](/llm/markdown/cloud/integrations/gitlab.md#Merge-Request-comments), or [Bitbucket](/llm/markdown/cloud/integrations/bitbucket.md#Pull-Request-comments)) so Cypress Cloud comments on each pull request with the run summary and a link straight to Branch Review. See [Monitor changes](/llm/markdown/ui-coverage/guides/monitor-changes.md#Step-1-Record-runs-on-a-regular-cadence). ### Can I see UI Coverage trends across all my projects? Yes. [Enterprise Reporting](/llm/markdown/cloud/features/analytics/enterprise-reporting.md#UI-Coverage) in Cypress Cloud rolls UI Coverage trends up across every project in your organization rather than one run at a time. You can view high-level trends, download reports, or pull the numbers through the [data extract API](/llm/markdown/cloud/integrations/data-extract-api.md) to build your own dashboards. See [Track trends across projects](/llm/markdown/ui-coverage/guides/monitor-changes.md#Step-4-Track-trends-across-projects). ## Reducing test duplication ### What is test duplication in Cypress UI Coverage? Test duplication is when many separate tests exercise the same interactive element to pass _through_ a flow rather than to test it, such as every test clicking a **Log in** or **Continue** button during setup. UI Coverage surfaces it in the **Tested elements** section, where those shared setup steps rise to the top on interaction and test count. It's wasted suite time, not a coverage gap: the element is tested, just redundantly. See [Reduce test duplication](/llm/markdown/ui-coverage/guides/reduce-test-duplication.md). ### How do I find elements my tests exercise more than they need to? Open the **Tested elements** section of the Cypress UI Coverage report. It lists every interactive element your tests exercised, with an **Interactions** column (how many times a command targeted it) and a **Tests** column (how many separate tests touched it), and it's sorted by interactions with the most-exercised elements first. A control that a large share of your suite interacts with, such as a **Log in** or **Continue** button, is usually shared setup being repeated across tests. Expand a row to break its counts down by view and open [Test Replay](/llm/markdown/cloud/features/test-replay.md) on each occurrence. See [Reduce test duplication](/llm/markdown/ui-coverage/guides/reduce-test-duplication.md). ### What's the difference between the Interactions and Tests columns in UI Coverage? In Cypress UI Coverage, **Interactions** counts every recognized command against an element across the run, so one test that hits a control in a loop can run the number up on its own. **Tests** counts the distinct tests that interacted with it, so a high number there means many _separate_ tests all touch the same control. The **Tests** column is the better signal for duplication, because shared setup repeated across your suite shows up as one element touched by a large share of your tests. ### How do I reduce test duplication? Use Cypress UI Coverage to find the elements at the top of the **Tested elements** list, confirm with [Test Replay](/llm/markdown/cloud/features/test-replay.md) that the tests are passing _through_ a flow rather than testing it, then replace the repeated UI steps with a single programmatic step: cache authentication with [`cy.session()`](/llm/markdown/api/commands/session.md), set a cookie or storage flag directly, or seed state with [`cy.request()`](/llm/markdown/api/commands/request.md). Keep one test that still drives the flow through the UI so its coverage is preserved. The [Reduce test duplication](/llm/markdown/ui-coverage/guides/reduce-test-duplication.md) guide walks through the full workflow. ### Does reducing test duplication lower my UI Coverage score? No. In Cypress UI Coverage, an element stays tested as long as at least one test still interacts with it, so consolidating redundant setup removes _interactions_, not _coverage_. When you replace a UI login in 200 tests with [`cy.session()`](/llm/markdown/api/commands/session.md) and keep one test that drives the login form, the form's interaction count drops sharply while it remains marked as tested, and your overall score is unchanged. ### What's the difference between reducing noise and reducing test duplication in UI Coverage? [Reducing noise](/llm/markdown/ui-coverage/guides/reduce-noise.md) is a report-accuracy problem: the report over-counts because one control is reported as many elements, or unrelated pages are split into separate views, and you fix it with [App Quality configuration](/llm/markdown/ui-coverage/configuration/overview.md) in Cypress Cloud. [Reducing test duplication](/llm/markdown/ui-coverage/guides/reduce-test-duplication.md) is a test-effort problem: the report is correct, but your suite repeats the same setup across many tests, and you fix it in your test code by consolidating that setup. ## Interactive elements ### What does Cypress UI Coverage count as an interactive element? UI Coverage follows the WHATWG definition of [interactive content](https://html.spec.whatwg.org/dev/dom.html#interactive-content), plus a few Cypress-specific rules. In short, an element counts when it is natively interactive (like ``, `