{
  "doc": {
    "id": "ui-coverage/guides/compare-reports",
    "title": "Compare UI Coverage reports across runs",
    "description": "Compare two UI Coverage reports to see which parts of your UI lost or gained test coverage between runs, using Branch Review in Cypress Cloud or the Cypress Cloud MCP from your editor, so you can catch new gaps before they merge.",
    "section": "ui-coverage",
    "source_path": "/llm/markdown/ui-coverage/guides/compare-reports.md",
    "version": "fbc9225067c51c52ee13224e3b702cf8a025ec12",
    "updated_at": "2026-08-14T12:36:26.878Z",
    "headings": [
      {
        "id": "ui-coverage/guides/compare-reports#compare-reports",
        "text": "Compare reports",
        "level": 1
      },
      {
        "id": "ui-coverage/guides/compare-reports#use-cases",
        "text": "Use cases",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/compare-reports#compare-reports-in-cypress-cloud",
        "text": "Compare reports in Cypress Cloud",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/compare-reports#step-1-open-branch-review-and-choose-your-two-runs",
        "text": "Step 1: Open Branch Review and choose your two runs",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#step-2-read-the-coverage-score-and-element-changes",
        "text": "Step 2: Read the coverage-score and element changes",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#step-3-review-new-untested-elements-and-links",
        "text": "Step 3: Review new untested elements and links",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#untested-elements",
        "text": "Untested elements",
        "level": 4
      },
      {
        "id": "ui-coverage/guides/compare-reports#untested-links",
        "text": "Untested links",
        "level": 4
      },
      {
        "id": "ui-coverage/guides/compare-reports#step-4-see-what-the-change-added",
        "text": "Step 4: See what the change added",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#step-5-drill-into-a-changed-item",
        "text": "Step 5: Drill into a changed item",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#step-6-stabilize-the-comparison-with-configuration",
        "text": "Step 6: Stabilize the comparison with configuration",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#compare-reports-with-the-cypress-cloud-mcp",
        "text": "Compare reports with the Cypress Cloud MCP",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/compare-reports#what-the-agent-uses",
        "text": "What the agent uses",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#example-prompts",
        "text": "Example prompts",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#keep-a-human-in-the-loop",
        "text": "Keep a human in the loop",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/compare-reports#see-also",
        "text": "See also",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "ui-coverage/guides/compare-reports#use-cases",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Use cases",
      "heading_level": 2,
      "content_markdown": "## Use cases\n\nComparing two runs is useful whenever you need to know how coverage _moved_, not just where it stands:\n\n*   **Pre-merge checks**: catch any interactive elements or pages a pull request leaves newly untested, before the change ships.\n*   **Confirming a fix**: prove a gap you set out to close is now tested, and that the view's score went up.\n*   **Monitoring changes**: compare nightly runs to catch coverage drifting down from an unexpected application change.\n*   **Reviewing AI-generated changes**: AI-generated tests and application code can quietly drop or duplicate coverage. The diff makes the impact of the change explicit.\n*   **Tracing a regression**: with a dropdown for each run, rapidly compare different A/B runs to find the exact commit that introduced a gap.\n*   **Sharing results with your team**: hand a reviewer a focused before/after instead of two full reports to review.\n",
      "section": "ui-coverage",
      "anchors": [
        "use-cases"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 193
    },
    {
      "id": "ui-coverage/guides/compare-reports#compare-reports-in-cypress-cloud",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Compare reports in Cypress Cloud",
      "heading_level": 2,
      "content_markdown": "## Compare reports in Cypress Cloud\n\nBranch Review gives you the full visual diff: the coverage-score change, the elements and pages that changed status, and full-page DOM snapshots that put each finding in context. Work through the steps below to go from two runs to a reviewed, trustworthy list of what changed.\n\n### Step 1: Open Branch Review and choose your two runs\n\nOpen the [Branch Review](/llm/markdown/cloud/features/branch-review.md) area of Cypress Cloud. You can get there by clicking the branch name associated with a run, or in [several other ways](/llm/markdown/cloud/features/branch-review.md#Get-started). Each run is chosen from a dropdown labeled **Base** and **Changed**.\n\nBranch Review compares any two runs recorded to Cypress Cloud, so no source control integration is required: the Git branch and commit for each run are captured automatically when it records, and you can select the two runs to compare manually.\n\nConnecting your project to a source control provider adds convenience on top of manual selection: you can select runs by their associated pull request, and Cypress picks the two runs for you. Cypress Cloud integrates with:\n\n*   [GitHub](/llm/markdown/cloud/integrations/github.md#Install-the-Cypress-GitHub-app)\n*   [GitLab](/llm/markdown/cloud/integrations/gitlab.md)\n*   [Bitbucket](/llm/markdown/cloud/integrations/bitbucket.md)\n\nFor the diff to be meaningful, both runs should have exercised a **similar set of tests over similar content**, so each run visited roughly the same pages and completed the same workflows. When that's true, any difference in the results is down to the change itself, which is what happens out of the box when you compare a pull-request branch against its base.\n\nYou can still compare runs from different points in time with different test results, as long as you keep the other sources of difference in mind as you read the diff. To see unified changes for your whole suite, group all of a commit's tests under a single Cypress run for each report. See the [Branch Review best practices](/llm/markdown/cloud/features/branch-review.md#Best-Practices) for how to group runs.\n\n### Step 2: Read the coverage-score and element changes\n\nStart with the headline: the change in overall coverage score between the two runs. Branch Review shows the delta as a badge: a positive value when the score rose and a negative one when it fell, comparing the changed run's score against the base run's.\n\nThis gives you a sense of whether the overall ratio of tested to untested elements has changed. It is a useful high-level signal, but it does not describe _what_ changed in the set of tested or untested items.\n\nEven if the score has not changed, review any new untested elements. They may represent missing coverage on new features.\n\nFor example, if a code change adds 2 buttons and you only test one of them, that would introduce one new tested element and one new untested element at the same time, keeping the ratio, and the score, flat.\n\n### Step 3: Review new untested elements and links\n\nTwo sections surface coverage that **regressed**: parts of the UI that are untested in the changed run but weren't a gap in the base run. These are the sections to watch on a pull request.\n\n**Tip:** Reviewing the element diffs regularly helps your team:\n\n*   **Spread out maintenance** of your coverage into small increments\n*   **Take ownership of** changes in the test suite by explicitly deciding whether to ignore new elements\n*   **Communicate quickly** with developers or AI agents adding user-facing functionality without coverage\n\n#### Untested elements\n\nThe **Untested elements** section separates the interactive elements into:\n\n*   **New untested elements**: elements that are untested in the changed run and were either tested in the base run or didn't exist there. This is the bucket a pull request review focuses on.\n*   **Resolved untested elements**: elements that were untested in the base run and are now tested. This is your proof that a gap was closed.\n*   **Existing untested elements**: a link to the elements that are untested in both runs, so you can jump to the full report when you want the complete picture rather than only the diff.\n\nA **new untested element** appears for one of three reasons, and all are worth reviewing:\n\n1.  The element still exists, but the **test code changed** so that nothing interacts with it anymore.\n2.  The **application code changed**, adding new elements that no test covers yet. These display with a green \"plus\" icon.\n3.  Your tests now capture **new views or snapshots** that weren't rendered in the previous run, so their interactive elements enter the report for the first time and need coverage.\n\nThe cause differs, but the fix is the same: exercise the element with a test so it contributes to your coverage score, or [ignore it with configuration](/llm/markdown/ui-coverage/guides/ignore-elements.md) if it isn't worth testing. See [Address coverage gaps](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md) for how to close a gap.\n\n#### Untested links\n\nThe **Untested links** section works the same way, but for whole pages. [Untested links](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links) are unopened doors in your application: pages a user can reach through your UI that no test visits. Like elements, they're split into:\n\n*   **New untested links**: a page that is reachable but untested in the changed run and wasn't an untested link in the base run.\n*   **Resolved untested links**: pages that were untested links in the base run and are now visited by a test.\n*   **Existing untested links**: a link to the untested links present in both runs.\n\nA new untested link is often the first sign that a change added a whole flow your suite doesn't reach yet. Visiting that page in a test also creates a [view](/llm/markdown/ui-coverage/core-concepts/views.md) for it, which then surfaces its own untested elements to work through.\n\n### Step 4: See what the change added\n\nThe **Added** section summarizes everything that is new in the changed run and wasn't present in the base run. Unlike the untested sections, it includes both tested and untested items, so it's the clearest view of how the application itself changed between the two runs, and whether your tests kept pace. It's grouped into:\n\n*   **Added links**: new links the change introduced, showing where new navigation paths appear in your app.\n*   **Added elements**: new interactive elements the change introduced. A batch that's all untested is a feature that shipped without coverage.\n*   **Added views**: new pages or states the change introduced, telling you which parts of the app became reachable for the first time.\n\nBecause it counts both tested and untested items, the Added section is a useful way to compare two builds of your application independent of the coverage score.\n\n### Step 5: Drill into a changed item\n\nClicking any new or resolved item opens a detail view of that item, where you see every example of that element or link on a full-page, inspectable DOM snapshot, with tested elements highlighted green and untested elements red. Items with the same status on both runs are removed here, so you focus only on what changed.\n\nThe detail view shows the changed run's snapshots, consistent with the changed run being the focal point of the comparison. Because the snapshot is a real DOM, you can open your browser's developer tools on it to understand _why_ an element went untested, for example because it's now behind a menu or only renders after a step your tests no longer reach. That context tells you what a new test needs to do.\n\n### Step 6: Stabilize the comparison with configuration\n\nOn most projects, comparing reports works well out of the box. But dynamic values in URLs or element attributes can make unchanged parts of your app _look_ like they changed, adding noise to the diff. Because UI Coverage is configured from the **App Quality** tab of your project settings in Cypress Cloud, you can fix this without touching your tests, then regenerate a past run from its **Properties** tab to see the effect immediately.\n\n**Stabilize views** so a page matches across runs. UI Coverage groups URLs that differ only by numeric IDs or UUIDs automatically (`/orders/123` and `/orders/456` become `/orders/*`), but other dynamic segments, such as slugs, are not grouped by default and can show up as \"new\" views between runs. Group them with a [`views`](/llm/markdown/ui-coverage/configuration/views.md) pattern:\n\nApp Quality Config\n\n```\n{  \"views\": [    {      \"pattern\": \"https://www.my-app.com/products/:slug\"    }  ]}\n```\n\nThis groups `/products/blue-widget` and `/products/red-widget` into a single `/products/:slug` view that's recognized the same way in both runs.\n\n**Stabilize elements** so the same control isn't matched as two different elements between builds. If an element's identifier carries a per-build hash, the same element can appear as _resolved_ in the base run and _new untested_ in the changed run even though nothing really changed. UI Coverage already ignores the most common unstable identifiers, such as hashed CSS classes; for anything it doesn't cover, exclude the unstable attribute with [`attributeFilters`](/llm/markdown/ui-coverage/configuration/attributefilters.md):\n\nApp Quality Config\n\n```\n{  \"attributeFilters\": [    {      \"attribute\": \"id\",      \"value\": \"input-[a-f0-9]{6}\",      \"include\": false,      \"comment\": \"IDs carry a per-build hash, so the same field appears as resolved on the base run and new untested on the changed run\"    }  ]}\n```\n\nThe [Reduce noise](/llm/markdown/ui-coverage/guides/reduce-noise.md) guide covers the other common adjustments. With the noise removed, a clean diff means nothing changed, and anything the diff shows is a real change worth reviewing.\n",
      "section": "ui-coverage",
      "anchors": [
        "compare-reports-in-cypress-cloud"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 2024
    },
    {
      "id": "ui-coverage/guides/compare-reports#step-1-open-branch-review-and-choose-your-two-runs",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Step 1: Open Branch Review and choose your two runs",
      "heading_level": 3,
      "content_markdown": "### Step 1: Open Branch Review and choose your two runs\n\nOpen the [Branch Review](/llm/markdown/cloud/features/branch-review.md) area of Cypress Cloud. You can get there by clicking the branch name associated with a run, or in [several other ways](/llm/markdown/cloud/features/branch-review.md#Get-started). Each run is chosen from a dropdown labeled **Base** and **Changed**.\n\nBranch Review compares any two runs recorded to Cypress Cloud, so no source control integration is required: the Git branch and commit for each run are captured automatically when it records, and you can select the two runs to compare manually.\n\nConnecting your project to a source control provider adds convenience on top of manual selection: you can select runs by their associated pull request, and Cypress picks the two runs for you. Cypress Cloud integrates with:\n\n*   [GitHub](/llm/markdown/cloud/integrations/github.md#Install-the-Cypress-GitHub-app)\n*   [GitLab](/llm/markdown/cloud/integrations/gitlab.md)\n*   [Bitbucket](/llm/markdown/cloud/integrations/bitbucket.md)\n\nFor the diff to be meaningful, both runs should have exercised a **similar set of tests over similar content**, so each run visited roughly the same pages and completed the same workflows. When that's true, any difference in the results is down to the change itself, which is what happens out of the box when you compare a pull-request branch against its base.\n\nYou can still compare runs from different points in time with different test results, as long as you keep the other sources of difference in mind as you read the diff. To see unified changes for your whole suite, group all of a commit's tests under a single Cypress run for each report. See the [Branch Review best practices](/llm/markdown/cloud/features/branch-review.md#Best-Practices) for how to group runs.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-1-open-branch-review-and-choose-your-two-runs"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 344
    },
    {
      "id": "ui-coverage/guides/compare-reports#step-2-read-the-coverage-score-and-element-changes",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Step 2: Read the coverage-score and element changes",
      "heading_level": 3,
      "content_markdown": "### Step 2: Read the coverage-score and element changes\n\nStart with the headline: the change in overall coverage score between the two runs. Branch Review shows the delta as a badge: a positive value when the score rose and a negative one when it fell, comparing the changed run's score against the base run's.\n\nThis gives you a sense of whether the overall ratio of tested to untested elements has changed. It is a useful high-level signal, but it does not describe _what_ changed in the set of tested or untested items.\n\nEven if the score has not changed, review any new untested elements. They may represent missing coverage on new features.\n\nFor example, if a code change adds 2 buttons and you only test one of them, that would introduce one new tested element and one new untested element at the same time, keeping the ratio, and the score, flat.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-2-read-the-coverage-score-and-element-changes"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 201
    },
    {
      "id": "ui-coverage/guides/compare-reports#step-3-review-new-untested-elements-and-links",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Step 3: Review new untested elements and links",
      "heading_level": 3,
      "content_markdown": "### Step 3: Review new untested elements and links\n\nTwo sections surface coverage that **regressed**: parts of the UI that are untested in the changed run but weren't a gap in the base run. These are the sections to watch on a pull request.\n\n**Tip:** Reviewing the element diffs regularly helps your team:\n\n*   **Spread out maintenance** of your coverage into small increments\n*   **Take ownership of** changes in the test suite by explicitly deciding whether to ignore new elements\n*   **Communicate quickly** with developers or AI agents adding user-facing functionality without coverage\n\n#### Untested elements\n\nThe **Untested elements** section separates the interactive elements into:\n\n*   **New untested elements**: elements that are untested in the changed run and were either tested in the base run or didn't exist there. This is the bucket a pull request review focuses on.\n*   **Resolved untested elements**: elements that were untested in the base run and are now tested. This is your proof that a gap was closed.\n*   **Existing untested elements**: a link to the elements that are untested in both runs, so you can jump to the full report when you want the complete picture rather than only the diff.\n\nA **new untested element** appears for one of three reasons, and all are worth reviewing:\n\n1.  The element still exists, but the **test code changed** so that nothing interacts with it anymore.\n2.  The **application code changed**, adding new elements that no test covers yet. These display with a green \"plus\" icon.\n3.  Your tests now capture **new views or snapshots** that weren't rendered in the previous run, so their interactive elements enter the report for the first time and need coverage.\n\nThe cause differs, but the fix is the same: exercise the element with a test so it contributes to your coverage score, or [ignore it with configuration](/llm/markdown/ui-coverage/guides/ignore-elements.md) if it isn't worth testing. See [Address coverage gaps](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md) for how to close a gap.\n\n#### Untested links\n\nThe **Untested links** section works the same way, but for whole pages. [Untested links](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links) are unopened doors in your application: pages a user can reach through your UI that no test visits. Like elements, they're split into:\n\n*   **New untested links**: a page that is reachable but untested in the changed run and wasn't an untested link in the base run.\n*   **Resolved untested links**: pages that were untested links in the base run and are now visited by a test.\n*   **Existing untested links**: a link to the untested links present in both runs.\n\nA new untested link is often the first sign that a change added a whole flow your suite doesn't reach yet. Visiting that page in a test also creates a [view](/llm/markdown/ui-coverage/core-concepts/views.md) for it, which then surfaces its own untested elements to work through.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-3-review-new-untested-elements-and-links"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 617
    },
    {
      "id": "ui-coverage/guides/compare-reports#untested-elements",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Untested elements",
      "heading_level": 4,
      "content_markdown": "#### Untested elements\n\nThe **Untested elements** section separates the interactive elements into:\n\n*   **New untested elements**: elements that are untested in the changed run and were either tested in the base run or didn't exist there. This is the bucket a pull request review focuses on.\n*   **Resolved untested elements**: elements that were untested in the base run and are now tested. This is your proof that a gap was closed.\n*   **Existing untested elements**: a link to the elements that are untested in both runs, so you can jump to the full report when you want the complete picture rather than only the diff.\n\nA **new untested element** appears for one of three reasons, and all are worth reviewing:\n\n1.  The element still exists, but the **test code changed** so that nothing interacts with it anymore.\n2.  The **application code changed**, adding new elements that no test covers yet. These display with a green \"plus\" icon.\n3.  Your tests now capture **new views or snapshots** that weren't rendered in the previous run, so their interactive elements enter the report for the first time and need coverage.\n\nThe cause differs, but the fix is the same: exercise the element with a test so it contributes to your coverage score, or [ignore it with configuration](/llm/markdown/ui-coverage/guides/ignore-elements.md) if it isn't worth testing. See [Address coverage gaps](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md) for how to close a gap.\n",
      "section": "ui-coverage",
      "anchors": [
        "untested-elements"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 305
    },
    {
      "id": "ui-coverage/guides/compare-reports#untested-links",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Untested links",
      "heading_level": 4,
      "content_markdown": "#### Untested links\n\nThe **Untested links** section works the same way, but for whole pages. [Untested links](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Untested-Links) are unopened doors in your application: pages a user can reach through your UI that no test visits. Like elements, they're split into:\n\n*   **New untested links**: a page that is reachable but untested in the changed run and wasn't an untested link in the base run.\n*   **Resolved untested links**: pages that were untested links in the base run and are now visited by a test.\n*   **Existing untested links**: a link to the untested links present in both runs.\n\nA new untested link is often the first sign that a change added a whole flow your suite doesn't reach yet. Visiting that page in a test also creates a [view](/llm/markdown/ui-coverage/core-concepts/views.md) for it, which then surfaces its own untested elements to work through.\n",
      "section": "ui-coverage",
      "anchors": [
        "untested-links"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 188
    },
    {
      "id": "ui-coverage/guides/compare-reports#step-4-see-what-the-change-added",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Step 4: See what the change added",
      "heading_level": 3,
      "content_markdown": "### Step 4: See what the change added\n\nThe **Added** section summarizes everything that is new in the changed run and wasn't present in the base run. Unlike the untested sections, it includes both tested and untested items, so it's the clearest view of how the application itself changed between the two runs, and whether your tests kept pace. It's grouped into:\n\n*   **Added links**: new links the change introduced, showing where new navigation paths appear in your app.\n*   **Added elements**: new interactive elements the change introduced. A batch that's all untested is a feature that shipped without coverage.\n*   **Added views**: new pages or states the change introduced, telling you which parts of the app became reachable for the first time.\n\nBecause it counts both tested and untested items, the Added section is a useful way to compare two builds of your application independent of the coverage score.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-4-see-what-the-change-added"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 200
    },
    {
      "id": "ui-coverage/guides/compare-reports#step-5-drill-into-a-changed-item",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Step 5: Drill into a changed item",
      "heading_level": 3,
      "content_markdown": "### Step 5: Drill into a changed item\n\nClicking any new or resolved item opens a detail view of that item, where you see every example of that element or link on a full-page, inspectable DOM snapshot, with tested elements highlighted green and untested elements red. Items with the same status on both runs are removed here, so you focus only on what changed.\n\nThe detail view shows the changed run's snapshots, consistent with the changed run being the focal point of the comparison. Because the snapshot is a real DOM, you can open your browser's developer tools on it to understand _why_ an element went untested, for example because it's now behind a menu or only renders after a step your tests no longer reach. That context tells you what a new test needs to do.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-5-drill-into-a-changed-item"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 183
    },
    {
      "id": "ui-coverage/guides/compare-reports#step-6-stabilize-the-comparison-with-configuration",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Step 6: Stabilize the comparison with configuration",
      "heading_level": 3,
      "content_markdown": "### Step 6: Stabilize the comparison with configuration\n\nOn most projects, comparing reports works well out of the box. But dynamic values in URLs or element attributes can make unchanged parts of your app _look_ like they changed, adding noise to the diff. Because UI Coverage is configured from the **App Quality** tab of your project settings in Cypress Cloud, you can fix this without touching your tests, then regenerate a past run from its **Properties** tab to see the effect immediately.\n\n**Stabilize views** so a page matches across runs. UI Coverage groups URLs that differ only by numeric IDs or UUIDs automatically (`/orders/123` and `/orders/456` become `/orders/*`), but other dynamic segments, such as slugs, are not grouped by default and can show up as \"new\" views between runs. Group them with a [`views`](/llm/markdown/ui-coverage/configuration/views.md) pattern:\n\nApp Quality Config\n\n```\n{  \"views\": [    {      \"pattern\": \"https://www.my-app.com/products/:slug\"    }  ]}\n```\n\nThis groups `/products/blue-widget` and `/products/red-widget` into a single `/products/:slug` view that's recognized the same way in both runs.\n\n**Stabilize elements** so the same control isn't matched as two different elements between builds. If an element's identifier carries a per-build hash, the same element can appear as _resolved_ in the base run and _new untested_ in the changed run even though nothing really changed. UI Coverage already ignores the most common unstable identifiers, such as hashed CSS classes; for anything it doesn't cover, exclude the unstable attribute with [`attributeFilters`](/llm/markdown/ui-coverage/configuration/attributefilters.md):\n\nApp Quality Config\n\n```\n{  \"attributeFilters\": [    {      \"attribute\": \"id\",      \"value\": \"input-[a-f0-9]{6}\",      \"include\": false,      \"comment\": \"IDs carry a per-build hash, so the same field appears as resolved on the base run and new untested on the changed run\"    }  ]}\n```\n\nThe [Reduce noise](/llm/markdown/ui-coverage/guides/reduce-noise.md) guide covers the other common adjustments. With the noise removed, a clean diff means nothing changed, and anything the diff shows is a real change worth reviewing.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-6-stabilize-the-comparison-with-configuration"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 409
    },
    {
      "id": "ui-coverage/guides/compare-reports#compare-reports-with-the-cypress-cloud-mcp",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Compare reports with the Cypress Cloud MCP",
      "heading_level": 2,
      "content_markdown": "## Compare reports with the Cypress Cloud MCP\n\n[Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) gives a compatible AI agent structured access to your UI Coverage data, so you can compare two runs without leaving your editor. Point the agent at a base run and a changed run, and it pulls the coverage for each and reports what changed: the score delta, the newly untested elements and links, and where to add the interactions that close them.\n\nUnlike Branch Review, there's no single \"compare\" call. The agent assembles the diff from a few read-only tools, which also means it can go straight from the diff to drafting the test that fixes it, using the specs and custom commands already in your project. What it can't show is the full-page DOM snapshots Branch Review renders, so reach for the two methods together: the MCP to find and act on the diff, and [Branch Review](#Compare-reports-in-Cypress-Cloud) when you want to see a change in context.\n\n### What the agent uses\n\nYou don't call these tools directly. You ask for a comparison in plain language, and the agent chooses and runs the right tools for you. The comparison draws on these Cloud MCP tools (see the [full list](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools)):\n\n*   [`cypress_get_runs`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): find the two runs to compare from a branch, project, or run URL.\n*   [`cypress_get_ui_coverage_report`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): the overall score, tested and untested counts, and riskiest views for each run.\n*   [`cypress_get_ui_coverage_views`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): browse every view in a run to compare coverage view by view.\n*   [`cypress_get_ui_coverage_elements`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): list the tested or untested elements in a run, optionally scoped to a single view, to see exactly which controls changed status.\n\nThe agent reads a run's coverage from each of the two runs and compares them, so the same guidance from [Step 1](#Step-1-Open-Branch-Review-and-choose-your-two-runs) applies: the cleanest comparison is between two runs that exercised a similar set of tests over similar content.\n\nCloud MCP must be enabled for your organization, and your agent must be authenticated, before these tools are available. See [Configuring the Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md#Configuring-the-Cloud-MCP).\n\n### Example prompts\n\nCopy one of these prompts into your AI coding assistant, filling in the run URLs or view names for your project.\n\nCompare coverage against the base branch\n\nReports what your change left newly untested versus main, and where to fix it.\n\nUsing Cypress Cloud MCP, pull the UI Coverage report for the latest run on this branch and for the latest run on main. Compare them and tell me: the change in overall coverage score, the interactive elements and links that are untested now but were tested (or didn't exist) on main, and the views where coverage dropped. For the highest-priority regression, name the spec file I should update and draft the interaction that would cover it.\n\nConfirm a gap you closed\n\nVerifies the elements you targeted are now tested.\n\nUsing Cypress Cloud MCP, compare the UI Coverage for run <BASE\\_RUN\\_URL> with the latest run on this branch. Confirm the elements that were untested on the <VIEW\\_NAME> view in the base run are now tested in the latest run, and list anything on <VIEW\\_NAME> that is still untested.\n\nExplain a drop in coverage\n\nPinpoints the views and elements behind a coverage drop.\n\nUsing Cypress Cloud MCP, the UI Coverage score dropped between run <BASE\\_RUN\\_URL> and run <CHANGED\\_RUN\\_URL>. Compare the two runs, list the views and untested elements responsible for the drop, and for each one tell me whether it looks like a test-code change (an element that used to be tested) or a new part of the application.\n\nFor more UI Coverage prompt patterns, see [Work with AI agents](/llm/markdown/ui-coverage/work-with-ai-agents.md).\n\n### Keep a human in the loop\n\nAn agent is good at assembling the diff and drafting a fix, but whether a drop in coverage is acceptable is a judgment call. A lower score after a deliberate scope change is fine; the same drop from a test that quietly stopped interacting with a control is not. Treat unexpected coverage movement as a quality gate: let the agent narrate the diff and propose tests, and have a reviewer confirm intent and risk before merging. See [Review and enforce coverage](/llm/markdown/ui-coverage/work-with-ai-agents.md#Review-and-enforce-coverage).\n",
      "section": "ui-coverage",
      "anchors": [
        "compare-reports-with-the-cypress-cloud-mcp"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 909
    },
    {
      "id": "ui-coverage/guides/compare-reports#what-the-agent-uses",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "What the agent uses",
      "heading_level": 3,
      "content_markdown": "### What the agent uses\n\nYou don't call these tools directly. You ask for a comparison in plain language, and the agent chooses and runs the right tools for you. The comparison draws on these Cloud MCP tools (see the [full list](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools)):\n\n*   [`cypress_get_runs`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): find the two runs to compare from a branch, project, or run URL.\n*   [`cypress_get_ui_coverage_report`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): the overall score, tested and untested counts, and riskiest views for each run.\n*   [`cypress_get_ui_coverage_views`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): browse every view in a run to compare coverage view by view.\n*   [`cypress_get_ui_coverage_elements`](/llm/markdown/cloud/integrations/cloud-mcp.md#Available-tools): list the tested or untested elements in a run, optionally scoped to a single view, to see exactly which controls changed status.\n\nThe agent reads a run's coverage from each of the two runs and compares them, so the same guidance from [Step 1](#Step-1-Open-Branch-Review-and-choose-your-two-runs) applies: the cleanest comparison is between two runs that exercised a similar set of tests over similar content.\n\nCloud MCP must be enabled for your organization, and your agent must be authenticated, before these tools are available. See [Configuring the Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md#Configuring-the-Cloud-MCP).\n",
      "section": "ui-coverage",
      "anchors": [
        "what-the-agent-uses"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 232
    },
    {
      "id": "ui-coverage/guides/compare-reports#example-prompts",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Example prompts",
      "heading_level": 3,
      "content_markdown": "### Example prompts\n\nCopy one of these prompts into your AI coding assistant, filling in the run URLs or view names for your project.\n\nCompare coverage against the base branch\n\nReports what your change left newly untested versus main, and where to fix it.\n\nUsing Cypress Cloud MCP, pull the UI Coverage report for the latest run on this branch and for the latest run on main. Compare them and tell me: the change in overall coverage score, the interactive elements and links that are untested now but were tested (or didn't exist) on main, and the views where coverage dropped. For the highest-priority regression, name the spec file I should update and draft the interaction that would cover it.\n\nConfirm a gap you closed\n\nVerifies the elements you targeted are now tested.\n\nUsing Cypress Cloud MCP, compare the UI Coverage for run <BASE\\_RUN\\_URL> with the latest run on this branch. Confirm the elements that were untested on the <VIEW\\_NAME> view in the base run are now tested in the latest run, and list anything on <VIEW\\_NAME> that is still untested.\n\nExplain a drop in coverage\n\nPinpoints the views and elements behind a coverage drop.\n\nUsing Cypress Cloud MCP, the UI Coverage score dropped between run <BASE\\_RUN\\_URL> and run <CHANGED\\_RUN\\_URL>. Compare the two runs, list the views and untested elements responsible for the drop, and for each one tell me whether it looks like a test-code change (an element that used to be tested) or a new part of the application.\n\nFor more UI Coverage prompt patterns, see [Work with AI agents](/llm/markdown/ui-coverage/work-with-ai-agents.md).\n",
      "section": "ui-coverage",
      "anchors": [
        "example-prompts"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 349
    },
    {
      "id": "ui-coverage/guides/compare-reports#keep-a-human-in-the-loop",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "Keep a human in the loop",
      "heading_level": 3,
      "content_markdown": "### Keep a human in the loop\n\nAn agent is good at assembling the diff and drafting a fix, but whether a drop in coverage is acceptable is a judgment call. A lower score after a deliberate scope change is fine; the same drop from a test that quietly stopped interacting with a control is not. Treat unexpected coverage movement as a quality gate: let the agent narrate the diff and propose tests, and have a reviewer confirm intent and risk before merging. See [Review and enforce coverage](/llm/markdown/ui-coverage/work-with-ai-agents.md#Review-and-enforce-coverage).\n",
      "section": "ui-coverage",
      "anchors": [
        "keep-a-human-in-the-loop"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 117
    },
    {
      "id": "ui-coverage/guides/compare-reports#see-also",
      "doc_id": "ui-coverage/guides/compare-reports",
      "heading": "See also",
      "heading_level": 2,
      "content_markdown": "## See also\n\n*   [Identify coverage gaps](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md): read a single report to find the untested elements and pages behind your score.\n*   [Address coverage gaps](/llm/markdown/ui-coverage/guides/address-coverage-gaps.md): close the gaps this diff surfaces, then confirm they stay closed.\n*   [Monitor changes](/llm/markdown/ui-coverage/guides/monitor-changes.md): track your score over time so new gaps don't slip in.\n*   [Block pull requests and set policies](/llm/markdown/ui-coverage/guides/block-pull-requests.md): enforce a coverage threshold in CI with the [Results API](/llm/markdown/ui-coverage/results-api.md).\n*   [Reduce noise](/llm/markdown/ui-coverage/guides/reduce-noise.md): remove the dynamic values and third-party elements that make a diff harder to read.\n*   [Branch Review](/llm/markdown/cloud/features/branch-review.md): how run comparison works across all of Cypress Cloud.\n*   [Work with AI agents](/llm/markdown/ui-coverage/work-with-ai-agents.md): use the Cypress Cloud MCP to summarize gaps and draft targeted tests from your editor.\n*   [Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md): set up the MCP server and see the full list of tools your agent can call.\n*   [UI Coverage FAQ](/llm/markdown/ui-coverage/faq.md): answers to common questions about scores, views, links, and configuration.\n",
      "section": "ui-coverage",
      "anchors": [
        "see-also"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/compare-reports.json",
      "token_estimate": 199
    }
  ]
}