Cursor Agent Review for QA is most useful when you test the reviewer itself instead of assuming every comment is correct. Build a controlled branch, seed realistic defects into an automated-test diff, run the local review, reproduce accepted findings, and measure what the reviewer found, missed, or incorrectly flagged.

This tutorial gives QA engineers and SDETs a screenshot-friendly workflow for reviewing AI-generated Playwright, Cypress, Selenium, API, or unit-test changes before commit. The result is an evidence pack that complements deterministic tests and human review; it is not an automatic merge decision.

Why test an AI test-code review?

Cursor’s official reviewing and testing guidance warns that AI-generated code can look correct while still missing edge cases, duplicating logic, or introducing security issues. It says the quality bar should remain the same whether code was written by a person or an agent.

Agent Review is a local review surface. After an agent finishes, Cursor documents the Review then Find Issues flow for a line-by-line pass over proposed edits. From Source Control, Agent Review can compare the full local change set with the main branch. That makes it a useful pre-commit checkpoint, but its findings remain hypotheses until reproduced.

What you will build

Create a disposable branch containing one legitimate test improvement and five seeded defects. Your audit should answer:

  • Which seeded defects were detected?
  • Which findings were reproducible?
  • Which comments were false positives, duplicates, or outside scope?
  • Did the generated change still pass lint, type checks, and targeted tests?
  • Would a human reviewer approve, revise, or reject the diff?

Step 1: Start from a stable QA baseline

Use a small repository or a dedicated training fixture. Record the base commit, browser and runtime versions, package-lock checksum, test command, and expected baseline result. Run the target test at least three times before changing it so a pre-existing flaky failure does not get credited to the review.

git switch -c qa/cursor-agent-review-lab
npm ci
npx playwright test tests/checkout.spec.ts --repeat-each=3
npm run lint
npm run typecheck

Save the clean results with a run ID. If the baseline is not green, stop and repair or document it before evaluating the reviewer.

Step 2: Design a seeded-defect matrix

Use synthetic defects that represent real test-maintenance risks. Do not seed dangerous production commands, real credentials, or destructive database operations.

ID Seeded defect Expected reviewer concern
SEED-01 Replace a role-based locator with a broad CSS selector Selector is brittle or can match the wrong element
SEED-02 Weaken an exact assertion to a truthy check The test can pass without verifying the requirement
SEED-03 Add a fixed browser delay before an assertion The delay is slow and does not synchronize with the real condition
SEED-04 Mutate a shared fixture without restoring it Later tests may become order-dependent
SEED-05 Remove an awaited asynchronous action The assertion can race with the application update

Keep a private answer key outside the agent conversation. The reviewer should see the code and repository context, not a list that reveals exactly what to flag.

Step 3: Add narrowly scoped QA review guidance

If your repository already uses Cursor Rules, add a test-path rule that describes stable team expectations rather than the seeded answers. Cursor’s official Rules documentation supports persistent, contextual project guidance.

---
description: Review automated tests for behavioral confidence
globs:
  - "tests/**/*"
  - "e2e/**/*"
---

When reviewing tests:
- connect each assertion to a stated requirement
- prefer user-visible, resilient locators
- flag fixed delays when a condition can be awaited
- check fixture isolation and cleanup
- check awaited asynchronous actions
- do not claim a defect until evidence is identified

Commit or preserve the rule as part of the controlled setup, and record whether the rule was active. Do not change the guidance between comparison runs unless rule effectiveness is the variable you intend to test.

Step 4: Ask the agent for one legitimate change

Give Cursor a bounded request such as adding a negative checkout test. Specify the target file, acceptance criteria, existing fixture pattern, and commands that must pass. Review the live diff while the agent works.

Add one Playwright test proving an expired discount code shows the existing error message and does not change the order total. Reuse current fixtures and locator patterns. Change only the checkout test and its dedicated fixture. Run the targeted test, lint, and type check. Summarize evidence and remaining uncertainty.

The official agent best-practices guide recommends specific prompts, verifiable goals, and careful diff review. If the live diff expands into application code or unrelated tests, stop and redirect before evaluation. A controlled review is meaningless when task scope keeps changing.

Step 5: Apply the defect seeds without changing the goal

Introduce the five defects into the resulting test diff, one per identifiable hunk. Preserve the valid scenario so the branch still looks plausible. Record each seed’s file and line range, but keep that mapping out of Cursor’s immediate context.

Capture the complete diff checksum:

git diff --binary main...HEAD > review-lab.patch
sha256sum review-lab.patch

On Windows, use your approved checksum utility or PowerShell file-hash command. The important point is to prove that repeated review trials evaluated the same change.

Step 6: Run Cursor Agent Review

First review the agent’s proposed edits through Review then Find Issues. Then open Source Control and run Agent Review against the complete local change set compared with main. For a manual companion pass, Cursor also documents using @Branch to give the agent the full branch diff.

Review this branch as a QA automation change. Identify behavioral gaps, flaky synchronization, weak assertions, locator risk, fixture leakage, missing cleanup, and unrelated edits. For every finding, cite the file, the changed behavior, and a deterministic reproduction step. Do not propose a fix yet.

Export or screenshot findings before accepting any suggested edits. A review result can change after the diff changes, so evidence must stay tied to the captured checksum.

Step 7: Classify every finding

Use a table rather than free-form notes:

Finding ID Seed link Disposition Evidence
AR-01 SEED-03 Confirmed Condition-based wait passes; fixed delay flakes under throttling
AR-02 None False positive Claim contradicts the fixture implementation
AR-03 SEED-04 Confirmed Reverse-order run fails without cleanup

Allowed dispositions should include confirmed, false positive, duplicate, already covered, out of scope, and insufficient evidence. Never mark a comment confirmed only because its explanation sounds persuasive.

Step 8: Reproduce findings independently

For each accepted issue, add a minimal deterministic check or demonstrate the failure with the existing test runner. Useful verification commands include:

npx playwright test tests/checkout.spec.ts --repeat-each=5
npx playwright test tests/checkout.spec.ts --workers=1
npx playwright test tests/checkout.spec.ts --workers=4
npm run lint
npm run typecheck

Vary worker count and execution order for isolation defects. Use controlled latency or a test double for synchronization defects. Validate locator findings against the rendered accessible UI, not only DOM source. Preserve trace, screenshot, console, and network evidence when relevant, but redact tokens and personal data.

Step 9: Measure detection quality

Calculate two simple metrics:

  • Seed recall: detected seeded defects divided by total seeded defects.
  • Finding precision: independently confirmed findings divided by all actionable findings.

Run at least three trials against the identical diff and compare variance. Also record time-to-review, duplicate count, findings without reproduction steps, and how often a suggested fix changes intended test behavior. These measurements describe your controlled sample; they are not universal product benchmarks.

Negative cases for the review workflow

  • A large unrelated formatting diff hides a one-line assertion regression.
  • A generated test passes because both implementation and assertion encode the same wrong assumption.
  • The branch baseline is stale compared with main.
  • A finding cites unchanged code rather than the proposed edit.
  • Two comments describe the same underlying fixture leak.
  • The reviewer proposes deleting an assertion to make the test pass.
  • The review completes with no findings even though the seeded defect remains reproducible.
  • A suggested fix passes the target test but fails the full regression suite.

Release gate

Do not accept the branch merely because Agent Review reports no issues. Cursor’s official guidance says tests, type checking, linting, and human review work together, and it explicitly notes that passing tests do not guarantee correct behavior.

  • The diff remains within the approved task scope.
  • Every accepted finding has independent evidence.
  • All seeded defects are removed or explicitly dispositioned.
  • Targeted and full regression checks pass from a clean environment.
  • Test assertions still prove the user requirement.
  • A human reviewer approves the final diff and evidence.

What Cursor Agent Review does not prove

Agent Review does not prove complete defect detection, correct requirements, reliable test data, secure code, accessibility, privacy compliance, or release readiness. Treat it as a fast second set of eyes. Deterministic checks, source-controlled evidence, specialist review, and human merge authority remain the real quality gates.

Official Cursor sources