Skip to main content
UI CoveragePremium Solution

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.

info

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 and Ignore views and links. 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.

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 reference for all options.

caution

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 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 and Attribute Filters 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 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.

The Properties tab for a run, with an Application Quality section where you can regenerate the report with the current configuration

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​

Contents