---
id: ui-coverage/guides/reduce-noise
title: Reduce noise in UI Coverage reports
description: >-
  A workflow for turning a noisy UI Coverage report into an actionable one:
  recognize the noise, diagnose its cause, apply the matching fix, and validate.
section: ui-coverage
source_path: docs/ui-coverage/guides/reduce-noise.mdx
version: 4df0c75e373515c33269176d556219950487e085
updated_at: '2026-08-22T19:13:35.211Z'
---
# Reduce noise

By default, UI Coverage reports every interactive element it finds, with built-in grouping for repeated elements.

For many projects, you will want to adjust the default identification and grouping of the elements to match your team's goals and how you think about coverage. For example, an action might be possible from dozens of different locations within a page (like an "edit" button on every item in a list). In most cases, UI Coverage will group such actions together based on the repeated DOM structure so that testing **any of the instances** counts as testing **the whole group**.

But sometimes what appears as an "untested element" by default isn't a gap your team would care about. It might be the same button counted many times, one element whose generated ID keeps changing, or dozens of near-identical pages listed as separate views. Left alone, this noise hides the gaps that actually matter.

This guide recommends a workflow for cleaning that up:

*   **Recognize** the noise.
*   **Diagnose** what's causing it.
*   **Apply** the matching configuration.
*   **Validate** the result.

Each fix below is a small piece of configuration, but the value is in knowing _which_ one to reach for.

This guide is about consolidating and stabilizing elements that _should_ be in your report. To remove elements or pages entirely (third-party widgets, admin pages, error routes), see [Ignore elements](/llm/markdown/ui-coverage/guides/ignore-elements.md) and [Ignore views and links](/llm/markdown/ui-coverage/guides/ignore-views-and-links.md). This guide assumes you have already removed unwanted elements from the report. If you haven't, do that first, as it will make the rest of the work much easier.

## Step 1: Recognize the noise

Open the **UI Coverage** tab for a recent run and look for these patterns:

*   **One element appears many times.** A control with the same purpose shows up as several separate untested entries, often because its `id` or another attribute is generated fresh on each render.
*   **A group of similar elements each listed separately.** A navigation bar, list, or set of form fields where every item is its own entry, inflating the count without adding insight.
*   **Too many views.** Pages that differ only by a slug (`/products/wireless-mouse`, `/products/usb-c-cable`) appear as distinct views, spreading coverage across pages you think of as one.
*   **Elements identified by unstable attributes.** Selectors in the report are built from stateful or hashed attributes (like a `data-headlessui-state` toggle or a hashed `css-1a2b3c` class) instead of the stable attributes your team recognizes. This can produce noise between pages, but also between runs when using Branch Review to [compare reports](/llm/markdown/ui-coverage/guides/compare-reports.md).

## Step 2: Diagnose and apply the matching fix

Each pattern from Step 1 maps to one of the fixes below. Configure them in the **App Quality** tab of your project settings, under the `uiCoverage` key.

### Many similar elements → group them

When several elements share the same function and differ only by a generated value, group them into a single entry with `elementGroups`. This is the right choice for a control that repeats, such as an action button on every row of a list.

Given a list of rows that each repeat the same action, where the button's `id` is generated from the row's record ID:

```
<ul class="cart">
  <li>
    Wireless Mouse
    <button id="remove-item-8a2f">Remove</button>
  </li>
  <li>
    USB-C Cable
    <button id="remove-item-3d9b">Remove</button>
  </li>
  <li>
    Laptop Stand
    <button id="remove-item-c710">Remove</button>
  </li>
</ul>
```

Every **Remove** button does the same thing, so you want to know that interaction is covered without tracking each row separately. Group them by their stable prefix:

App Quality Config

```
{
  "uiCoverage": {
    "elementGroups": [
      {
        "selector": ".cart [id^='remove-item-']"
      }
    ]
  }
}
```

The report now shows a single entry instead of three, named `.cart [id^='remove-item-']` with a badge showing the number of grouped elements. Hovering the badge reads _3 instances grouped by configuration_.

See the [Element Groups](/llm/markdown/ui-coverage/configuration/elementgroups.md) reference for all options.

Group only elements that share the same purpose. Grouping controls that do different things, or distinct links you want covered separately, hides real gaps instead of reducing noise.

### One element splitting into many → stabilize its identity

When a _single_ element appears as several untested entries because a generated attribute changes between snapshots, identify it by a selector you choose with an `elements` rule, and optionally give it a readable name:

App Quality Config

```
{
  "uiCoverage": {
    "elements": [
      {
        "selector": "input[id^='downshift-'][id$='-input']",
        "name": "Search input"
      }
    ]
  }
}
```

The rule applies only when its selector matches exactly one interactive element in a snapshot. If many elements share the same generated attribute, group them with `elementGroups` (above) or filter the attribute (below) instead. See the [Elements](/llm/markdown/ui-coverage/configuration/elements.md) reference for details.

### Noisy or meaningless attributes → tune identification

If elements are being identified by the wrong attributes, steer Cypress toward the attributes you care about and away from the ones you don't.

Prioritize your own stable attributes with `significantAttributes`:

App Quality Config

```
{
  "uiCoverage": {
    "significantAttributes": ["data-testid"]
  }
}
```

Cypress already filters the most common unstable attributes, so use `attributeFilters` only for the ones it misses. This example keeps your `data-cy` hook while ignoring the `data-*` state attributes component libraries toggle as the UI changes:

App Quality Config

```
{
  "uiCoverage": {
    "attributeFilters": [
      {
        "attribute": "data-cy",
        "include": true,
        "comment": "Always identify elements by our test hook"
      },
      {
        "attribute": "data-.*",
        "include": false,
        "comment": "Ignore library state attributes like data-state, data-headlessui-state"
      }
    ]
  }
}
```

See the [Significant Attributes](/llm/markdown/ui-coverage/configuration/significantattributes.md) and [Attribute Filters](/llm/markdown/ui-coverage/configuration/attributefilters.md) references for the full matching rules.

### Too many near-identical pages → group views

Cypress groups URLs that differ only by numeric IDs or UUIDs automatically, but not ones that differ by a slug or name. When these product pages share a template you want reported as one view, consolidate them with a `views` pattern:

```
/products/wireless-mouse
/products/wireless-mouse?ref=email
/products/usb-c-cable
/products/laptop-stand#reviews
```

Collapse them into one view. Leaving the protocol and hostname off the pattern lets it match these paths on any environment your tests run against:

App Quality Config

```
{
  "uiCoverage": {
    "views": [
      {
        "pattern": "/products/*"
      }
    ]
  }
}
```

See the [Views](/llm/markdown/ui-coverage/configuration/views.md) reference for pattern syntax.

## Step 3: Validate the result

Configuration changes are applied when a report is generated, so you don't need to rerun your tests to see their effect. After saving your configuration, regenerate a recent run from its **Properties** tab.

Then reopen the UI Coverage report and confirm that:

*   The elements you grouped now appear as a single entry.
*   The element you stabilized no longer splits across snapshots.
*   The views you consolidated are reported together.
*   The overall element and view counts have dropped to reflect real coverage rather than duplication.

If new noise appears in future reports as your application grows, repeat this loop (recognize, diagnose, apply, validate) to keep the report actionable.

## See also

*   [Ignore elements](/llm/markdown/ui-coverage/guides/ignore-elements.md): remove elements from the report entirely instead of grouping them.
*   [Ignore views and links](/llm/markdown/ui-coverage/guides/ignore-views-and-links.md): remove whole pages from the report.
*   [Element Identification](/llm/markdown/ui-coverage/core-concepts/element-identification.md) and [Element Grouping](/llm/markdown/ui-coverage/core-concepts/element-grouping.md): the concepts behind how Cypress identifies and consolidates elements.
*   [Reduce test duplication](/llm/markdown/ui-coverage/guides/reduce-test-duplication.md): the test-effort counterpart to this report-accuracy guide, for when the report is right but too many tests exercise the same control.
