UI CoveragePremium Solution

Views

A view in UI Coverage is a distinct page or state of your application, created by grouping the URLs your tests visit into URL patterns. In component tests, each spec file is a view.

Views turn a run's raw coverage data into a page-by-page breakdown you can act on. When your report shows /checkout at 95% and /settings/* at 40%, you can weigh each area's coverage against how critical it is to your users and decide where the next test belongs. Views show you:

• Where coverage is strong: views with high scores confirm which areas of your application are well tested.
• Where the gaps are: views with low scores, and untested views discovered from links, show exactly which pages need attention.
• How to prioritize: per-view scores let you focus testing effort on the most critical areas of your application first.

What makes a view

Views come from two sources, depending on testing type:

• End-to-end tests: The unique URLs across all snapshots are consolidated into URL patterns. Each pattern becomes a view.
• Component tests: Each spec file becomes a single view, named by the spec's file path. All components mounted within a spec are grouped into that view.

How views are created

Every URL visited in an end-to-end run passes through three steps, in order:

1. Filtering: URLs excluded by your viewFilters configuration are removed from the report.
2. Your patterns: The remaining URLs are matched against your views configuration patterns, in the order they're listed. The first matching pattern wins.
3. Automatic grouping: Any URLs that didn't match one of your patterns are grouped by the automatic rules below.

The automatic rules consolidate the dynamic URLs that represent the same page into a single view. They reduce noise so that your report reflects the structure of your application, not the number of records in your test data:

• Dynamic segments: Any path segment that is a number or an ID is replaced with a wildcard (*). A segment counts as an ID when it is a UUID, a UUID-shaped hexadecimal value (even if not a strictly valid UUID), or a string of 20 or more hexadecimal characters. This applies even when only one URL matches the pattern, so /orders/123 becomes /orders/* on its own.
• Query parameters: Query strings are ignored when grouping, so URLs that differ only by query parameters become a single view, and view names do not include a query string.
• Hash routing: If a URL's hash begins with #/, UI Coverage treats your application as using hash-based routing. Each hash route becomes its own view, and the dynamic segment rules also apply within the hash. Hashes that do not begin with #/ (e.g., #section-2) are ignored.
• Trailing slashes: URLs that differ only by a trailing slash are the same view.
• Common origins: When all views share the same protocol, host, and port, view names omit them for readability.

Examples

Visited URLs	Resulting view
/users/123/profile, /users/456/profile	/users/*/profile
/orders/f14005b2-6e14-4ac2-b41c-4dcd48ee9dbc	/orders/*
/dashboard?tab=overview, /dashboard#section-2, /dashboard/	/dashboard
/app#/users/1, /app#/users/2	/app#/users/*
/app#/admin, /app#/settings	/app#/admin and /app#/settings (separate views)
/users/alice, /users/bob	/users/alice and /users/bob (separate views)

Note the last example: segments that are dynamic but are not numbers or IDs, like usernames, are not grouped automatically. Use the views configuration to group these yourself.

Views in your coverage report

The UI Coverage report lists every view along with:

• Snapshots: The number of snapshots captured for the view, which you can browse to see the states your tests produced.
• Tested elements: How many of the view's interactive elements were tested, out of the total found.
• Coverage score: The percentage of the view's interactive elements that were tested.

Your run's overall coverage score uses the same calculation across all included views combined: the total number of tested elements divided by the total number of interactive elements. Each view contributes in proportion to how many elements it contains, and excluding a view removes its elements from the score entirely.

Selecting a view drills into its elements so you can see exactly which ones your tests missed.

The report also surfaces untested views: pages that were never visited during your run, discovered from untested links found in the pages you did test. These highlight areas of your application with no coverage at all, along with the views that link to them.

Customizing views

Two configuration properties control how URLs become views. Note that both properties also affect Cypress Accessibility reports.

If your report shows	Try this
Many near-duplicate views, like /users/alice and /users/bob	Group them with a views pattern.
Third-party, admin, or error pages you don't intend to test	Exclude them with viewFilters.
A page missing from the report entirely	The page was never visited during the run. Check untested links for it, and confirm a viewFilters rule isn't excluding it unintentionally.

Grouping URLs into views

The views configuration defines your own URL patterns for grouping, using URL Pattern API syntax:

App Quality Config

{
  "views": [
    {
      "pattern": "https://cypress.io/users/*"
    }
  ]
}

Patterns with named parameters can also use groupBy to split one pattern into multiple views based on a parameter's values, such as one view per document type. See the views configuration documentation for the full syntax, matching rules, and worked examples.

Ignoring views

The viewFilters configuration excludes URLs you don't want tracked, such as third-party authentication pages:

App Quality Config

{
  "viewFilters": [
    {
      "pattern": "https://auth.example.com/*",
      "include": false
    }
  ]
}

See also

• views configuration covers the full syntax for grouping URLs into views, including groupBy.
• viewFilters configuration covers excluding URLs from your reports.
• Interactivity explains which elements count as interactive, which commands mark them as tested, and how untested links are tracked.
• Element identification explains how elements are identified within a view across snapshots.
• The Identify coverage gaps guide shows how to use views to find untested areas of your application.
• The Ignore views and links guide walks through excluding irrelevant views from your coverage scores.
• The UI Coverage FAQ answers common questions about view grouping and missing pages.