---
id: ui-coverage/core-concepts/views
title: 'Views: pages and components in UI Coverage'
description: >-
  How UI Coverage groups the URLs your tests visit into views: URL pattern
  rules, per-view coverage scores, and configuration to group or exclude URLs.
section: ui-coverage
source_path: docs/ui-coverage/core-concepts/views.mdx
version: 29f95bf8bb06f320986f3749f5bf09a35a409eab
updated_at: '2026-09-04T10:49:54.630Z'
---
# 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`](/llm/markdown/ui-coverage/configuration/viewfilters.md) configuration are removed from the report.
2.  **Your patterns**: The remaining URLs are matched against your [`views`](/llm/markdown/ui-coverage/configuration/views.md) 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 views share a protocol, host, and port, view names omit them for readability. In runs that span multiple origins, names are shortened wherever it's unambiguous.

### 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`](/llm/markdown/ui-coverage/configuration/views.md) 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](/llm/markdown/ui-coverage/core-concepts/element-identification.md) 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](/llm/markdown/ui-coverage/core-concepts/interactivity.md#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`](/llm/markdown/ui-coverage/configuration/views.md) pattern. |
| Third-party, admin, or error pages you don't intend to test | Exclude them with [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md). |
| A page missing from the report entirely | The page was never visited during the run. Check [untested links](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links) for it, and confirm a `viewFilters` rule isn't excluding it unintentionally. |

### Grouping URLs into views

The [`views`](/llm/markdown/ui-coverage/configuration/views.md) configuration defines your own URL patterns for grouping, using [URL Pattern API](https://developer.mozilla.org/en-US/docs/Web/API/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](/llm/markdown/ui-coverage/configuration/views.md) documentation for the full syntax, matching rules, and worked examples.

### Ignoring views

The [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) 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](/llm/markdown/ui-coverage/configuration/views.md) covers the full syntax for grouping URLs into views, including `groupBy`.
*   [`viewFilters` configuration](/llm/markdown/ui-coverage/configuration/viewfilters.md) covers excluding URLs from your reports.
*   [Interactivity](/llm/markdown/ui-coverage/core-concepts/interactivity.md) explains which elements count as interactive, which commands mark them as tested, and how untested links are tracked.
*   [Element identification](/llm/markdown/ui-coverage/core-concepts/element-identification.md) explains how elements are identified within a view across snapshots.
*   The [Identify coverage gaps](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md) guide shows how to use views to find untested areas of your application.
*   The [Ignore views and links](/llm/markdown/ui-coverage/guides/ignore-views-and-links.md) guide walks through excluding irrelevant views from your coverage scores.
*   The [UI Coverage FAQ](/llm/markdown/ui-coverage/faq.md) answers common questions about view grouping and missing pages.