> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testdino.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Debug Playwright Failures with AI

> Hand a failing test run or test case from TestDino to Claude Code, Cursor, or another MCP client and verify the fix held.

**Debug with AI** hands a failing test run or test case to your AI coding assistant with the scope already filled in. The assistant reads the failure from TestDino, proposes a fix in your repository, and confirms whether the fix held once a new test run lands.

## Prerequisites

Connect the TestDino MCP server first. The button copies an instruction that names your test run or test case, and the assistant needs MCP to read it.

* [Local MCP Server](/mcp/local) for Claude Code, Cursor, and Claude Desktop
* [Remote MCP Server](/mcp/remote) for ChatGPT and Claude on the web

## Where the button appears

| Surface          | Shows when                                                             | Hands over            |
| :--------------- | :--------------------------------------------------------------------- | :-------------------- |
| Test run header  | The test run has finished and has at least 1 failed or flaky test case | The whole test run    |
| Test case detail | The test case failed or is flaky, and its test run has finished        | That single test case |

The button stays hidden while a test run is still executing, and on a test run where nothing failed. A test run reporting `passed` still shows the button when it carries flaky test cases.

## Hand off a failure

<Steps>
  <Step title="Open the failing test run or test case">
    Click **Debug with AI** in the header. The instruction is copied to your clipboard.
  </Step>

  <Step title="Paste it into your assistant">
    Paste into Claude Code, Codex, VS Code, or any MCP client. The instruction names the project, the test run, and the test case, so you do not describe what you are looking at.
  </Step>

  <Step title="Review what it proposes">
    The assistant reads the evidence, then proposes a change. It asks before editing a file or running a command.
  </Step>

  <Step title="Verify the fix">
    Push the change and let CI upload a new test run. Ask the assistant to verify the fix, and it compares the new test run against the one you started from.
  </Step>
</Steps>

Open the chevron next to the button for the other hand-off paths:

| Option                          | Use it for                                                 |
| :------------------------------ | :--------------------------------------------------------- |
| Copy for Claude, Codex, VS Code | Any assistant you paste into                               |
| Open in Cursor                  | Opens Cursor with the instruction already in the prompt    |
| Set up TestDino MCP             | Opens the MCP setup dialog when you have not connected yet |

## What the assistant reads

The assistant reads current data from TestDino each time, so a hand-off you copied earlier is never out of date.

It pulls 3 things before proposing anything:

* Whether the failure repeats across retry attempts, or passed on one of them
* The last test run the test case passed, and the first one it failed
* The trace, screenshots, and the expected, actual, and diff images on a visual failure

Knowing the last test run a test case passed turns "why is this broken" into "what changed between these 2 test runs", which is a smaller question to answer.

## Fix a test case or check a flake

The single-test-case hand-off checks the retry evidence before proposing anything. A test case that fails identically on every attempt is not treated as flaky, and a test case that passed on retry does not get its assertion rewritten.

Verdicts describe behavior, not cause. They report which fixes the evidence rules out rather than naming a root cause:

| Verdict         | Not supported by this evidence                               |
| :-------------- | :----------------------------------------------------------- |
| `flaky`         | Changing the assertion, because the test case passed once    |
| `deterministic` | A wait, a longer timeout, more retries, or a wider tolerance |

## Triage a whole test run

The test run hand-off groups failures by shared cause and puts the largest group first, because one fix there often closes many test cases at once. On a large test run the assistant tells you when it is working from a sample rather than every affected test case.

## Verify the fix held

This is the step that closes the loop. After a new test run lands, ask the assistant to verify the fix. It compares that test run against the one you started from and reports one of:

| Status            | Meaning                                        |
| :---------------- | :--------------------------------------------- |
| `fixed`           | Passing with no retries since                  |
| `not_fixed`       | Still failing with the same error              |
| `changed_failure` | Still failing with a different error           |
| `unstable`        | Passing only after retries, which is not fixed |

A test case that passes only on a retry never reports `fixed`. That is the most common way a fix looks successful without being one.

<Warning>
  Fix suggestions are proposals to review, not changes to apply unread. Approving one action does not approve the next, and an assistant asks again before it commits.
</Warning>

## Related

<CardGroup cols={2}>
  <Card title="Debugging Basics" icon="bug" href="/guides/debug-playwright-test-failures">
    Evidence types and where to find them
  </Card>

  <Card title="MCP Tools Reference" icon="wrench" href="/mcp/tools-reference">
    Parameters for every debugging tool
  </Card>

  <Card title="Local MCP Server" icon="laptop-code" href="/mcp/local">
    Connect Claude Code, Cursor, or Claude Desktop
  </Card>

  <Card title="Flaky Test Detection" icon="repeat" href="/guides/playwright-flaky-test-detection">
    How TestDino identifies flaky test cases
  </Card>
</CardGroup>