Claude Code testing: prove the change works before Claude says done

Claude Code testing works when something other than Claude decides whether the change worked. Reticle is an MCP server Claude Code calls while it works: it drives the flow in your running web app and returns a pass or fail with evidence from the network, the app state and the console.

Why "done" from Claude Code is not proof

Claude Code writes the change, writes the tests, runs them and writes the summary. All four come from the same understanding of the task, so when that understanding is wrong, everything agrees and the summary still says "done".

This is common enough to have its own reports on Claude Code's tracker, including "Claude fabricates test results - reports ALL PASSED when tests are FAILING". The fix is structural, not a better prompt: the author should not grade its own work. The longer version is in how to use Claude Code for QA automation.

A green unit suite has the same blind spot. It checks the assertions someone chose to write, not what the app did. A click that fires the charge request twice passes every assertion that only looks at the screen. More on that in why a green check isn't proof.

Set up Reticle in Claude Code

The Claude Code plugin installs the skill and the MCP server in one step. Run these two commands inside Claude Code:

/plugin marketplace add reticlehq/reticle
/plugin install reticle@reticlehq

Restart Claude Code in your app's folder. At the start of the session, Claude offers to run reticle init, which adds the dev-only SDK to your app and drives one real flow to a verdict.

To register the MCP server by hand instead, once for every project:

claude mcp add reticle -s user -- npx @reticlehq/server mcp

Then wire the app from its folder with npx @reticlehq/server init (or reticle init if the CLI is installed). --dry-run shows the plan and writes nothing. Every step is in the Reticle README.

What the verify loop looks like

1. You ask Claude Code for a change, for example "add a refund button to the order page".
2. Claude edits the code, then calls Reticle to drive the flow in the running app.
3. Reticle reads what happened: the request and its status, how many times it fired, the store after the click, the console.
4. The verdict comes back as pass or fail. On a fail it names the evidence and, on React and Svelte, the file:line.
5. Claude fixes that line and verifies again. It says "done" after a pass, not before.

Each flow Claude drives is saved under .reticle/flows/. From then on, npx @reticlehq/server verify <url> replays them with no model in the loop and exits non-zero when one fails, so the same check runs in CI. Replaying one saved flow eight times gave the same verdict all eight times, and re-verifying a four-flow suite costs about 480 tokens (benchmark scorecard).

A prompt that works: "Record the login flow with Reticle, then re-verify it after every change."

Limits

• Full depth needs your app. Reticle also works on sites you don't own: it drives the page in its own browser, injects its SDK, and reads network, console, DOM and routing. App state and the file:line source pointer need the SDK built into your own app. For cross-browser runs, use Playwright MCP.
• One browser engine. Reticle runs on the engine your app runs on. Cross-browser matrices are Playwright's job.
• Not a pixel diff. In our own benchmark a CSS re-tint that changed 2.3% of the screen was caught by a screenshot and missed by Reticle's always-on read.
• Source lines on React and Svelte. Reticle works on React, Next.js, Vue, Svelte and Angular. Network, state and console checks work on all of them; the file:line pointer covers React and Svelte components, not Vue single-file components or Angular templates.

For how Reticle compares with the browser-driving MCP servers, see Reticle vs Playwright MCP and the MCP servers for browser testing overview.

FAQ

How do I test changes made by Claude Code?

Test changes made by Claude Code with a check that Claude does not write itself. Run the app, drive the changed flow, and read the network calls, state and console rather than the screen. Reticle does this as an MCP server Claude Code calls, returning a pass or fail with evidence and the line to fix.

Why does Claude Code say tests pass when the app is broken?

Claude Code says tests pass when the tests share its mistake. It writes the code and the tests from the same understanding, so a wrong assumption makes both wrong in the same direction. Sometimes it reports a run that never covered the change. An independent check of the running app catches what its own tests cannot.

Does Reticle work with the Claude Code plugin system?

Yes. Reticle ships a Claude Code plugin: run /plugin marketplace add reticlehq/reticle, then /plugin install reticle@reticlehq, and restart Claude Code in your app's folder. The plugin adds the skill and the MCP server, and Claude offers to run reticle init to wire your app at the start of the session.

Can Claude Code use Playwright MCP for testing instead?

Claude Code can use Playwright MCP to drive a browser and read the page, and that is the right tool for cross-browser work or zero-setup runs. It describes what the page shows. Reticle reads the app's own network, state and console from inside, and replays saved flows without a model.