Generate Missing Cypress Tests Faster with UI Coverage
Use Cypress UI Coverage to find untested views and interactions, add meaningful tests, and verify the results without treating a coverage score as a quality guarantee.
Short answer: Cypress UI Coverage helps you find candidate gaps in an existing Cypress suite by mapping visited pages and component states to interactive elements that tests exercised. Use its report to choose a user-important gap, add a test that asserts an outcome, then rerun and inspect the report. Coverage speeds discovery and prioritization; it does not prove your assertions are useful or guarantee a particular reduction in test-writing time.
UI Coverage analyzes pages visited by end-to-end tests and mounted components in component tests. It captures DOM snapshots, identifies interactive elements, and records whether Cypress interactions exercised them. End-to-end results are organized into views generally based on URL patterns; component results are grouped by spec file. The report can also surface links to views your run never visited.
1. Record a run and open UI Coverage
- Run the Cypress end-to-end or component tests that represent the journeys you want to review, and record the run in Cypress Cloud.
- Open the run’s UI Coverage report. Scan low-coverage views, untested interactive elements, and untested links.
- Start with a journey that matters to your users and is in scope for your application, such as sign-in, checkout, or account changes where those flows exist.
- Follow an untested link and determine whether it leads to an owned page you intend to test. A link to a third-party destination or an intentionally excluded area may not represent a missing test.
The view score is the percentage of its interactive elements that were tested. The overall score divides tested interactive elements by all interactive elements in included views, so larger views contribute more. Treat scores as a triage map, not a quality target: they do not establish whether tests assert the correct behavior.
2. Turn a reported gap into a meaningful test
Choose one uncovered control or view and describe the user outcome you expect. For example, a test should check that submitting a valid form reaches the expected confirmation state, rather than only clicking the submit button. Use the application’s actual route, selectors, fixtures, and expected behavior.
The following is a runnable Cypress pattern once you replace the example route and selectors with ones from your application. It illustrates an outcome assertion; it is not a claim about a specific app:
describe('account form', () => {
it('shows confirmation after a valid submission', () => {
cy.visit('/account');
cy.get('[data-cy="email"]').type('dev@example.com');
cy.get('[data-cy="submit"]').click();
cy.get('[data-cy="confirmation"]')
.should('be.visible')
.and('contain', 'Request received');
});
});
Prefer stable selectors such as dedicated test attributes when your application provides them. Keep setup deterministic, assert the result a user should observe, and check that the scenario adds behavior coverage instead of duplicating an existing test.
Can Cypress generate tests for uncovered UI?
Cypress product material describes AI test-case generation based on a customer’s own Cypress projects. Cypress Cloud MCP can make UI Coverage data available to an AI agent, which can surface risky untested views and point to an appropriate spec file. That helps with discovery and test drafting; generated code still needs review for setup, selectors, meaningful assertions, and maintainability. The available product material does not establish that every uncovered element can be converted into a correct test automatically or quantify a guaranteed time saving.
3. Rerun and verify what changed
- Run the relevant spec again and record a fresh Cypress Cloud run.
- Inspect the same view and confirm that the intended interaction is now counted.
- Review the test itself: confirm it fails when the expected behavior breaks and that its assertions check the outcome, not just the action.
- If the report still looks wrong, check interaction recognition and element identification before changing tests to chase a score.
Reports retain the configuration used when they were processed. After changing UI Coverage configuration, regenerate or reprocess the report before evaluating the effect.
How do I find missing Cypress tests?
Use UI Coverage as a map from existing test runs to user-facing views and interactive controls. Prioritize an uncovered owned view or control based on the user journey it supports, add a behavior-focused Cypress test, then rerun and verify both the assertion and the report. A low percentage alone is not a test plan: it can include out-of-scope UI, duplicate controls, or interactions Cypress did not recognize.
How can I see which parts of my UI are not covered by Cypress tests?
Open UI Coverage for a recorded Cloud run and inspect each view’s tested and untested elements and links. End-to-end views are generally based on URL patterns, while component views are associated with spec files. The report can infer untested views from links found on pages your tests visited. Those inferred pages are candidates to investigate, not proof that they belong in your test boundary.
Coverage approaches and when to use them
| Approach | What it shows | Useful for | Limit |
|---|---|---|---|
| Cypress UI Coverage | Views, states, and interactive elements observed in Cypress runs | Finding candidate user-facing gaps in an existing Cypress suite | Interaction coverage does not prove assertions are correct; it integrates with Cypress Cloud and is described as a separately purchased premium solution |
| Traditional code coverage | Executed source files, lines, or statements | Seeing which code ran | It does not directly map unexercised user-facing controls |
| Manual review of specs and requirements | Scenarios and expected behavior expressed in requirements and tests | Judging whether the right user outcomes are asserted | It does not automatically provide the same page-and-element map |
These approaches answer different questions and can complement one another. When evaluating UI Coverage, consider the cost and availability for your Cypress Cloud plan, the granularity of gaps you need, how you will exclude out-of-scope UI, and whether Cloud reports and agent workflows fit your process. Cypress describes UI Coverage as a premium solution purchased separately from standard Cloud plans; confirm current plan terms with Cypress. Its product page also describes report use in CI workflows for thresholds or build responses.
Troubleshooting UI Coverage results
| Symptom | Likely cause | What to check or change |
|---|---|---|
| A click appears in the test but the element remains untested | The interaction may not use a command UI Coverage recognizes | Check the supported interaction commands and configure additional interaction commands where appropriate. |
| The same control appears as several elements | Its identifying attributes vary across snapshots | Use stable identifiers and review significantAttributes and attributeFilters. |
| Different controls appear merged into one | Identifiers may be too generic | Give controls more distinctive stable attributes; review element grouping and attribute configuration. |
| A large number of unrelated views or links lowers the score | Dynamic URLs, third-party widgets, or out-of-scope destinations are included | Review view grouping and filters. Exclude genuinely out-of-scope pages, not owned pages merely to raise the percentage. |
| A configuration change does not affect an existing report | The report was processed with the earlier saved configuration | Regenerate or reprocess the report after editing configuration. |
| A generated test raises coverage but gives little confidence | The test may exercise a control without asserting its user-visible result | Strengthen the outcome assertion and review setup, selectors, and duplication. |
Performance, reliability, and cost considerations
- Run time: UI Coverage is based on captured snapshots from test runs. The reviewed source material does not give a general runtime overhead figure, so measure it in your own recorded runs before making CI timing assumptions.
- Reliability: Results depend on what the run visited, which interactions Cypress recognized, and how consistently elements are identified. Dynamic pages and unstable attributes can make the map noisy. A report is evidence for investigation, not a complete inventory of all possible behavior.
- Cost: Cypress describes UI Coverage as a separately purchased premium solution rather than part of standard Cypress Cloud plans. Check Cypress’s current terms before budgeting. No universal return-on-investment or test-writing speed figure is established by the material reviewed.
- Score interpretation: Overall coverage is weighted by the number of interactive elements in included views. Changing the view boundary can change the score, so keep exclusions aligned with the actual testing scope.
Or skip the browser setup
If you need screenshots of pages while investigating a UI issue or documenting a test case, ScreenshotNeo is a website screenshot API and MCP server. A single GET request captures a URL as PNG, JPEG, WebP, or PDF. See the API documentation for parameters and options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);
ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month, with no card required.
FAQ
Does a higher UI Coverage score mean my tests are good?
No. It reports exercised interactive elements, not whether assertions check the right result or whether important behavior is missing from the scenarios.
Does UI Coverage replace code coverage?
No. UI Coverage maps user-facing interactions; code coverage reports execution of source code. They provide different views of test coverage.
Can I use UI Coverage with component tests?
Yes. It analyzes mounted components, with views generally organized by spec file.
Will an AI agent write a correct test for every gap?
No such guarantee is established. Agents can use coverage data to identify risky views and relevant specs, but developers should review generated tests and their assertions.


