{
  "doc": {
    "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": "/llm/markdown/ui-coverage/core-concepts/views.md",
    "version": "29f95bf8bb06f320986f3749f5bf09a35a409eab",
    "updated_at": "2026-09-04T10:49:54.630Z",
    "headings": [
      {
        "id": "ui-coverage/core-concepts/views#views",
        "text": "Views",
        "level": 1
      },
      {
        "id": "ui-coverage/core-concepts/views#what-makes-a-view",
        "text": "What makes a view",
        "level": 2
      },
      {
        "id": "ui-coverage/core-concepts/views#how-views-are-created",
        "text": "How views are created",
        "level": 2
      },
      {
        "id": "ui-coverage/core-concepts/views#examples",
        "text": "Examples",
        "level": 3
      },
      {
        "id": "ui-coverage/core-concepts/views#views-in-your-coverage-report",
        "text": "Views in your coverage report",
        "level": 2
      },
      {
        "id": "ui-coverage/core-concepts/views#customizing-views",
        "text": "Customizing views",
        "level": 2
      },
      {
        "id": "ui-coverage/core-concepts/views#grouping-urls-into-views",
        "text": "Grouping URLs into views",
        "level": 3
      },
      {
        "id": "ui-coverage/core-concepts/views#ignoring-views",
        "text": "Ignoring views",
        "level": 3
      },
      {
        "id": "ui-coverage/core-concepts/views#see-also",
        "text": "See also",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "ui-coverage/core-concepts/views#what-makes-a-view",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "What makes a view",
      "heading_level": 2,
      "content_markdown": "## What makes a view\n\nViews come from two sources, depending on testing type:\n\n*   **End-to-end tests**: The unique URLs across all snapshots are consolidated into URL patterns. Each pattern becomes a view.\n*   **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.\n",
      "section": "ui-coverage",
      "anchors": [
        "what-makes-a-view"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 80
    },
    {
      "id": "ui-coverage/core-concepts/views#how-views-are-created",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "How views are created",
      "heading_level": 2,
      "content_markdown": "## How views are created\n\nEvery URL visited in an end-to-end run passes through three steps, in order:\n\n1.  **Filtering**: URLs excluded by your [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) configuration are removed from the report.\n2.  **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.\n3.  **Automatic grouping**: Any URLs that didn't match one of your patterns are grouped by the automatic rules below.\n\nThe 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:\n\n*   **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.\n*   **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.\n*   **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.\n*   **Trailing slashes**: URLs that differ only by a trailing slash are the same view.\n*   **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.\n\n### Examples\n\n| Visited URLs | Resulting view |\n| --- | --- |\n| `/users/123/profile`, `/users/456/profile` | `/users/*/profile` |\n| `/orders/f14005b2-6e14-4ac2-b41c-4dcd48ee9dbc` | `/orders/*` |\n| `/dashboard?tab=overview`, `/dashboard#section-2`, `/dashboard/` | `/dashboard` |\n| `/app#/users/1`, `/app#/users/2` | `/app#/users/*` |\n| `/app#/admin`, `/app#/settings` | `/app#/admin` and `/app#/settings` (separate views) |\n| `/users/alice`, `/users/bob` | `/users/alice` and `/users/bob` (separate views) |\n\nNote 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.\n",
      "section": "ui-coverage",
      "anchors": [
        "how-views-are-created"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 513
    },
    {
      "id": "ui-coverage/core-concepts/views#examples",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "Examples",
      "heading_level": 3,
      "content_markdown": "### Examples\n\n| Visited URLs | Resulting view |\n| --- | --- |\n| `/users/123/profile`, `/users/456/profile` | `/users/*/profile` |\n| `/orders/f14005b2-6e14-4ac2-b41c-4dcd48ee9dbc` | `/orders/*` |\n| `/dashboard?tab=overview`, `/dashboard#section-2`, `/dashboard/` | `/dashboard` |\n| `/app#/users/1`, `/app#/users/2` | `/app#/users/*` |\n| `/app#/admin`, `/app#/settings` | `/app#/admin` and `/app#/settings` (separate views) |\n| `/users/alice`, `/users/bob` | `/users/alice` and `/users/bob` (separate views) |\n\nNote 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.\n",
      "section": "ui-coverage",
      "anchors": [
        "examples"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 115
    },
    {
      "id": "ui-coverage/core-concepts/views#views-in-your-coverage-report",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "Views in your coverage report",
      "heading_level": 2,
      "content_markdown": "## Views in your coverage report\n\nThe UI Coverage report lists every view along with:\n\n*   **Snapshots**: The number of snapshots captured for the view, which you can browse to see the states your tests produced.\n*   **Tested elements**: How many of the view's interactive elements were tested, out of the total found.\n*   **Coverage score**: The percentage of the view's interactive elements that were tested.\n\nYour 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.\n\nSelecting 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.\n\nThe 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.\n",
      "section": "ui-coverage",
      "anchors": [
        "views-in-your-coverage-report"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 236
    },
    {
      "id": "ui-coverage/core-concepts/views#customizing-views",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "Customizing views",
      "heading_level": 2,
      "content_markdown": "## Customizing views\n\nTwo configuration properties control how URLs become views. Note that both properties also affect Cypress Accessibility reports.\n\n| If your report shows | Try this |\n| --- | --- |\n| Many near-duplicate views, like `/users/alice` and `/users/bob` | Group them with a [`views`](/llm/markdown/ui-coverage/configuration/views.md) pattern. |\n| Third-party, admin, or error pages you don't intend to test | Exclude them with [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md). |\n| 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. |\n\n### Grouping URLs into views\n\nThe [`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:\n\nApp Quality Config\n\n```\n{\n  \"views\": [\n    {\n      \"pattern\": \"https://cypress.io/users/*\"\n    }\n  ]\n}\n```\n\nPatterns 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.\n\n### Ignoring views\n\nThe [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) configuration excludes URLs you don't want tracked, such as third-party authentication pages:\n\nApp Quality Config\n\n```\n{\n  \"viewFilters\": [\n    {\n      \"pattern\": \"https://auth.example.com/*\",\n      \"include\": false\n    }\n  ]\n}\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "customizing-views"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 276
    },
    {
      "id": "ui-coverage/core-concepts/views#grouping-urls-into-views",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "Grouping URLs into views",
      "heading_level": 3,
      "content_markdown": "### Grouping URLs into views\n\nThe [`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:\n\nApp Quality Config\n\n```\n{\n  \"views\": [\n    {\n      \"pattern\": \"https://cypress.io/users/*\"\n    }\n  ]\n}\n```\n\nPatterns 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.\n",
      "section": "ui-coverage",
      "anchors": [
        "grouping-urls-into-views"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 100
    },
    {
      "id": "ui-coverage/core-concepts/views#ignoring-views",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "Ignoring views",
      "heading_level": 3,
      "content_markdown": "### Ignoring views\n\nThe [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) configuration excludes URLs you don't want tracked, such as third-party authentication pages:\n\nApp Quality Config\n\n```\n{\n  \"viewFilters\": [\n    {\n      \"pattern\": \"https://auth.example.com/*\",\n      \"include\": false\n    }\n  ]\n}\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "ignoring-views"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 44
    },
    {
      "id": "ui-coverage/core-concepts/views#see-also",
      "doc_id": "ui-coverage/core-concepts/views",
      "heading": "See also",
      "heading_level": 2,
      "content_markdown": "## See also\n\n*   [`views` configuration](/llm/markdown/ui-coverage/configuration/views.md) covers the full syntax for grouping URLs into views, including `groupBy`.\n*   [`viewFilters` configuration](/llm/markdown/ui-coverage/configuration/viewfilters.md) covers excluding URLs from your reports.\n*   [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.\n*   [Element identification](/llm/markdown/ui-coverage/core-concepts/element-identification.md) explains how elements are identified within a view across snapshots.\n*   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.\n*   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.\n*   The [UI Coverage FAQ](/llm/markdown/ui-coverage/faq.md) answers common questions about view grouping and missing pages.\n",
      "section": "ui-coverage",
      "anchors": [
        "see-also"
      ],
      "path": "/llm/json/chunked/ui-coverage/core-concepts/views.json",
      "token_estimate": 143
    }
  ]
}