---
id: ui-coverage/configuration/views
title: 'views: group URLs with URL patterns in UI Coverage'
description: >-
  The `views` configuration groups related URLs into a single view in UI
  Coverage using URL patterns, so reports and scores reflect the actual pages of
  your application.
section: ui-coverage
source_path: docs/ui-coverage/configuration/views.mdx
version: dd1b4f9adc7e2fae428f3afbd4b3686f68b7cdc9
updated_at: '2026-09-12T13:36:55.674Z'
---
# Group & name views - `views`

This page is the configuration reference for the `views` property. To learn how UI Coverage creates views by default, and when you'd reach for this property, see the [Views core concept](/llm/markdown/ui-coverage/core-concepts/views.md).

The `views` configuration groups the URLs your tests visit into views using URL patterns. Views are the distinct pages of your application that your reports are organized around. URLs that differ only by numeric IDs or UUIDs are grouped automatically (`/users/123` and `/users/456` become a single `/users/*` view), but other dynamic values are not: `/users/alice` and `/users/bob` appear as two separate views unless a `views` pattern groups them.

## Why use views?

*   **Group dynamic URLs**: Combine URLs with dynamic values that the automatic rules don't recognize, such as usernames or slugs, into a single view.
*   **Split views by query parameters**: By default, query strings are ignored when views are created, so `/home?status=done` and `/home?status=new` group into a single `/home` view. A pattern that captures a query parameter lets you report on them separately.
*   **Create distinct view groups**: Use `groupBy` to create a separate view for each value of a meaningful URL parameter, while still grouping the parts that are dynamic.
*   **Consolidate environments**: Patterns can span subdomains, or omit the protocol and hostname entirely, so the same page visited on different environments rolls up into one view.

## Scope

**Note:** setting `views` impacts both Accessibility and UI Coverage reports. It is defined at the root of your configuration and, unlike `viewFilters` and `elementFilters`, it cannot be nested under an `accessibility` or `uiCoverage` key to configure each product separately.

The `views` configuration applies to URLs visited in end-to-end tests. Views for component tests are created from the path of the spec file, and are not affected by this configuration.

## Syntax

App Quality Config

```
{
  "views": [
    {
      "pattern": string,
      "groupBy": string | [string],
      "comment": string
    }
  ]
}
```

A view can also be defined as just a pattern string when no other options are needed:

App Quality Config

```
{
  "views": ["https://www.my-app.com/users/*"]
}
```

### Options

| Option | Required | Default | Description |
| --- | --- | --- | --- |
| `pattern` | Required |  | A URL pattern to group matching URLs into a single view. Uses [URL Pattern API](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API) syntax. |
| `groupBy` | Optional |  | One or more named parameters from the pattern that should create separate views. Accepts a single string or an array of strings. Each name must appear in `pattern` as a named parameter (for example, `:type`), in the path, query string, or hash. |
| `comment` | Optional |  | A description of the purpose of this view configuration. Has no effect on behavior. |

## How are URLs matched to views?

*   Patterns are evaluated in the order they are defined, and each URL is grouped into the view of the first pattern it matches. A URL only ever belongs to one view.
*   URLs that don't match any pattern are grouped by the [automatic view grouping rules](/llm/markdown/ui-coverage/core-concepts/views.md#How-views-are-created), where possible.
*   A pattern that doesn't match any URLs in the run does not appear in the report.
*   URLs excluded by a `viewFilters` rule are excluded before `views` patterns are applied. A `views` pattern cannot bring an excluded URL back into the report.

Pattern matching follows [URL Pattern API](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API) semantics, with a few behaviors worth knowing:

*   A pattern that omits the query string and hash matches URLs with any query string or hash. For example, `https://www.my-app.com/users/*` matches `https://www.my-app.com/users/bob#settings`.
*   Trailing slashes are optional by default: `/users/bob` and `/users/bob/` both match a pattern ending in `/users/:name`. If your pattern ends with a `/`, only URLs with a trailing slash match it.
*   A pattern without a protocol and hostname, such as `/users/*`, matches that path on any protocol, hostname, and port.

## Using groupBy

The `groupBy` property creates distinct views based on named parameters in your URL pattern. For example, if your pattern is `/analytics/:type/:id`, using `groupBy: ["type"]` creates a separate view for each unique value of `type` (like `/analytics/performance/:id` and `/analytics/usage/:id`).

This is particularly useful when:

*   Different parameter values represent distinct functional areas
*   You want to track coverage separately for different categories of content
*   URL parameters determine significant UI changes

URLs with the same values for the specified parameters are grouped together, while different values create distinct views. Values can be captured from named parameters in the path, the query string, or the hash of the pattern.

## How views are named

A view created from your configuration is named by the pattern you wrote. When `groupBy` is used, the grouped parameters are replaced with their matched values, and any remaining named parameters and wildcards stay in the name, as the examples below show.

When every view in a report shares the same protocol and hostname, view names are displayed without them. The examples below show the names as they appear in this most common case.

## Examples

### Grouping dynamic path parameters

#### Config

App Quality Config

```
{
  "views": [
    {
      "pattern": "https://www.my-app.com/users/*"
    }
  ]
}
```

#### Visited URLs

```
https://www.my-app.com/users/alice
https://www.my-app.com/users/bob
https://www.my-app.com/users/bob#settings
https://www.my-app.com/users?assigned=true
```

#### Views shown in UI

```
/users/*
/users
```

The first three URLs match the pattern and group into `/users/*`. The last URL doesn't match (its path is `/users`, not `/users/` followed by more), so the automatic grouping rules create a `/users` view for it, with its query string ignored.

* * *

### Grouping with a named path parameter

A named parameter like `:name` matches a single path segment, just like `*`, but keeps a readable placeholder in the view name and can be referenced by `groupBy`.

#### Config

App Quality Config

```
{
  "views": [
    {
      "pattern": "https://www.my-app.com/users/:name"
    }
  ]
}
```

#### Visited URLs

```
https://www.my-app.com/users/alice
https://www.my-app.com/users/bob
https://www.my-app.com/users/bob#settings
https://www.my-app.com/users?assigned=true
```

#### Views shown in UI

```
/users/:name
/users
```

* * *

### Grouping by a path parameter

#### Config

App Quality Config

```
{
  "views": [
    {
      "pattern": "https://www.my-app.com/analytics/:type/:id",
      "groupBy": ["type"]
    }
  ]
}
```

#### Visited URLs

```
https://www.my-app.com/analytics/performance/amara
https://www.my-app.com/analytics/performance/harper
https://www.my-app.com/analytics/usage/amara
https://www.my-app.com/analytics/usage/harper
```

#### Views shown in UI

```
/analytics/performance/:id
/analytics/usage/:id
```

* * *

### Grouping by a query parameter

The `?*status=:status{&*}?` syntax captures the `status` query parameter wherever it appears in the query string, regardless of what other parameters surround it, and `#*` allows any hash.

#### Config

App Quality Config

```
{
  "views": [
    {
      "pattern": "https://www.my-app.com/home?*status=:status{&*}?#*",
      "groupBy": ["status"]
    }
  ]
}
```

#### Visited URLs

```
https://www.my-app.com/home?page=1&status=done
https://www.my-app.com/home?status=done&group=2
https://www.my-app.com/home?tag=trip&status=new&group=4
https://www.my-app.com/home?tag=trip&status=new#statusView
```

#### Views shown in UI

```
/home?*status=done{&*}?
/home?*status=new{&*}?
```

View names keep the query string portion of the pattern as you wrote it, with the grouped parameter replaced by its matched values.

* * *

### Grouping URLs across subdomains

Each unique value of `:path*` creates a view, and the same path visited on different subdomains is grouped into a single view. All of the views share the `*.my-app.com` hostname pattern, so it is omitted from the view names.

#### Config

App Quality Config

```
{
  "views": [
    {
      "pattern": "https://*.my-app.com/:path*",
      "groupBy": ["path"]
    }
  ]
}
```

#### Visited URLs

```
https://staging1.my-app.com/home
https://staging2.my-app.com/home
https://www.my-app.com/home
https://staging1.my-app.com/profile
https://www.my-app.com/profile/edit
```

#### Views shown in UI

```
/home
/profile
/profile/edit
```

## Troubleshooting

### A pattern you configured doesn't appear in the report

A pattern that doesn't match any URLs in the run is dropped from the report. Confirm that the pattern matches the full URL, including the protocol and hostname, or omit them so the pattern matches any origin. Also check that a `viewFilters` rule isn't excluding the URLs before `views` patterns are applied.

### Error: `Value "..." was not found in the pattern`

Each name in `groupBy` must appear in `pattern` as a named parameter. For example, `groupBy: ["type"]` requires `:type` somewhere in the pattern's path, query string, or hash.

### Error: `No duplicate values allowed - "..." was added multiple times`

Each pattern in `views` must be unique. Named parameters are compared as wildcards, so `/users/:name` and `/users/*` count as the same pattern and trigger this error.

## See also

*   [Views core concept](/llm/markdown/ui-coverage/core-concepts/views.md): how views are created by default and used in your report
*   [`viewFilters` configuration](/llm/markdown/ui-coverage/configuration/viewfilters.md): exclude URLs from your reports
*   [Ignore views and links guide](/llm/markdown/ui-coverage/guides/ignore-views-and-links.md): exclude irrelevant views from coverage scores
*   [UI Coverage FAQ](/llm/markdown/ui-coverage/faq.md): common questions about view grouping and missing pages