Test and debug with Cursor

Testing and debugging with Cursor is a three-guide section for developers who let Cursor’s agent write tests and fix bugs. The guides cover writing the failing test first, generating tests that catch real bugs in existing code, and finding a root cause before any fix. Each one ends with evidence a reviewer checks instead of reading the diff.

You asked Cursor’s agent for tests on a payment service. It wrote 30, every one passed, and coverage jumped. A week later a refactor broke refunds and not one test went red, because the tests asserted what the code already did, not what it should do. This section is for the developer who writes those prompts and the tech lead who decides what a test-bearing pull request must prove.

Which Cursor testing guide do you need?

Your situation	Start with	You leave with
New feature or behaviour change	Test-driven development in Cursor	A failing test written from the spec, then an implementation that turns it green
Existing code with few or weak tests	Testing patterns	Characterization tests, coverage for real edge cases, and test data factories
Something is broken, often intermittently	AI-assisted debugging in Cursor	A reproduction, a proven root cause, and a regression test that failed first

Prerequisites: a working agent setup and a test command the agent can run (Cursor quick start, project rules).

How the test-and-debug loop runs in Cursor

All three guides share one order, and the order stops the agent from writing tests that fit its own code.

Specify the behaviour in Plan Mode. Plan Mode “creates detailed implementation plans before writing any code”. Turn the request or bug report into acceptance criteria, with no edits.
Write the test and watch it fail. Cursor’s agent writes tests only; source files are off limits. A test that passes before the change exists tests nothing.
Implement with the tests locked. The agent changes source files until the suite is green, and does not edit the tests. Commit first so git diff --stat shows what it touched. An instruction is not a lock; enforce it with a CI check that fails when the implementation commit touches tests/ (protect the oracle).
Run every gate. The full test suite, the type check and the linter, locally and in CI.
Get an independent review. Bugbot or a second agent reviews the pull request against the acceptance criteria, not the agent’s own summary.

Do not change any file under src/. Only create or edit files under tests/.

Read @src/payment/refund.ts but treat it as possibly wrong. Write tests from
these rules, not from what the code currently does:
1. A refund can never exceed the captured amount minus earlier refunds.
2. A refund on a disputed payment is rejected with REFUND_BLOCKED.
3. Two concurrent refunds for the same payment cannot both succeed.

For each test, name the bug it would catch. Run the tests and report which
fail on the current code. Do not "fix" a failing test: a failure may be a real bug.

For each test you added in this session:
1. Make the smallest change to the source that should break it (flip a
   comparison, drop a guard, return early).
2. Run only that test and confirm it fails. Paste the failure line.
3. Revert the change and confirm the test passes again.
Report any test that stayed green when the code was broken, and rewrite its
assertion. When you finish, `git diff` on src/ must be empty.

How do you trust agent-written tests without reading them all?

Check that the tests can fail and that nobody bent them to fit the code. Require this on every pull request that adds or changes tests:

Red before green. Each new test fails on the old code, and the failing output goes into the pull request.
Break-it check. The second prompt above: a test that survives a deliberately broken line is decoration. Oracle strength explains how to measure this across a suite.
Tests untouched during the fix. git diff --stat for the implementation commit lists no test files.
Gates green in CI, not only in the agent’s report.

The developer owns the evidence. The reviewer approves when every item is present and reads code only where an item is missing or surprising. The reasoning is in reading evidence instead of code.

Which MCP server helps testing in Cursor?

For UI bugs and end-to-end checks, the official Playwright MCP server (@playwright/mcp 0.0.82, checked with npm view on 26 September 2026) lets the agent drive a real browser and read console errors. Add it to Cursor’s MCP configuration (mcp.json; see MCP setup):

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

Add --isolated to args when several agents test in parallel, because a persistent browser profile opens in only one browser at a time. Tool schemas and page snapshots cost context, so enable the server for UI work only. Alternatives are compared in Playwright MCP and testing and debugging skills.

What goes wrong with testing and debugging in Cursor?

Symptom	Likely cause	Recovery
All new tests pass on the first run	They were derived from the implementation	Rerun the first prompt with the rules stated and `src/` read-only
A failing test turns green after an edit to the test	The agent changed the assertion to fit the code	Revert the test, say “The test is correct; fix the implementation”, and check `git diff --stat`
Each fix breaks something else	The agent edited before the cause was known	Restore the last clean commit and return to Plan Mode (bug hunting)
Coverage rises, bugs still escape	Tests exercise lines without asserting outcomes	Run the break-it prompt on the module that leaked the bug
Green locally, red in CI	Different data, timing or environment	Reproduce with the CI command and seed data before asking for a fix

Where to go after testing in Cursor

Test-driven development in Cursor Write the failing test from the spec, then let the agent implement.

Testing patterns Tests for existing and legacy code that catch real regressions.

AI-assisted debugging in Cursor Investigate read-only, reproduce, fix one cause, and prove it.

Review and ship with Cursor The next stage: code review, Bugbot and CI gates before release.

The same stage for other tools: Claude Code and Codex. The tool-neutral practice lives in verification workflows.