How to Test and Verify Changes Made by Cursor

Agent can produce a plausible patch that still fails tests, breaks lint, or touches files outside scope. Verification is not a separate phase after Agent finishes. It belongs in the same prompt as the implementation. State the command that proves success, tell Agent to stop if it fails, and review the diff before you commit.

The same habits apply when you review a cloud agent pull request: read the diff, check artifacts, run trusted commands locally if the change is critical. Explore summary at /explore/cursor under Tests, terminal commands, and verification.

The verification workflow

Define expected behavior in plain language. Implement with Agent or review Agent output. Run automated tests and lint named in the prompt. Inspect failures and ask for minimal fixes. Rerun until green. Perform manual checks for UI or integration gaps tests miss. Review scope and secrets before merge.

Treat verification as a loop, not a gate at the end. When a test fails, paste the failure output and ask for the smallest fix. When lint fails, scope lint to changed files so Agent does not reformat the entire repository. When manual checks fail, describe what you saw on screen so Agent can adjust behavior.

Step by step verification loop

• Write done criteria before Agent edits
• Run the named test command inside the same Agent session
• Paste failures verbatim when tests break
• Ask for minimal fix, not rewrite
• Rerun until green
• Scan diff for scope creep
• Run manual checks for gaps tests miss

Put definition of done in every implementation prompt

Goal: fix duplicate submit on mobile Safari in ContactForm.
Done when: npm test -- --testPathPattern=ContactForm passes.
Scope: components/ContactForm.tsx and its test only.
After implementation: run the test command and paste failures verbatim.

Example: feature with build and test

@src/features/export/
Add CSV export for admin users on the reports table.
Done when:
1) npm test -- --testPathPattern=export passes
2) npm run lint passes on changed files
Scope: src/features/export/ only
Do not commit

Example: bug fix plus regression test

Fix null handling in parseConfig when config file is empty.
Add one test that fails on the old behavior.
Done when: npm test -- --testPathPattern=parseConfig passes.
Do not refactor unrelated modules.

Example: lint scoped to changed files

Implement the API change in src/app/api/webhooks/route.ts.
Then run npm run lint -- --file src/app/api/webhooks/route.ts
Fix only lint errors in files you changed.

Approve terminal commands deliberately

Depending on your settings, Agent asks before running shell commands. Read destructive commands carefully. Prefer project test and lint scripts over broad clean or reset commands unless you intended them. Enterprise and team policies may restrict auto run further.

Allowed: npm test, npm run lint, npm run build
Ask me before: rm -rf, git reset, database drop, curl against production

Example: end to end test command

@src/e2e/checkout.spec.ts
Update checkout e2e for new tax line item.
Done when: npx playwright test checkout.spec.ts passes headless.
Do not disable failing assertions; fix product code instead.

Example: security sensitive change

Scope: @src/middleware/auth.ts only
Change: validate JWT exp claim before handler runs.
Done when: auth.middleware.test.ts passes and no other files changed.
Manual: confirm 401 returned for expired token in dev.

Bugbot and agentic review on Teams

Teams plans document agentic code review with Bugbot on usage based billing per Cursor pricing pages. Automated review complements your test commands; it does not replace them. Run your own tests even when Bugbot passes.

Regression after you edit the diff manually

If you reject hunks or edit Agent output by hand, rerun the full verification command set. Partial manual edits often fix one test while breaking another file Agent touched earlier in the session.

I rejected formatting hunks in utils.ts manually.
Re run npm test and npm run lint on the whole diff stat.
Fix any new failures before commit.

Manual checks when tests are thin

Not every repo has full coverage. Name the page, route, or user role to exercise. List edge cases such as empty input, unauthorized access, slow network, and double submit.

Manual verify after Agent patch:
1. Start npm run dev
2. Log in as member, confirm settings toggle persists reload
3. Log in as admin, confirm toggle hidden
4. Report any console errors

Example: CI parity check

After local tests pass, run the same command CI uses:
npm run test:ci
If CI fails only on coverage, fix tests rather than lowering thresholds unless I approve.

Example: database migration verification

Agent added migration 20260822_add_status.sql
Verify:
1) npm run db:migrate on fresh database
2) npm run db:rollback one step
3) npm test -- --testPathPattern=status
Stop if rollback fails.

Review diff scope before commit

Agent sometimes formats or renames outside the requested module. Scan git diff for surprise files before commit. Reject drive by changes even when tests pass. Restore Checkpoint if the scope creep started mid session.

Verify cloud agent pull requests

Cloud agents open pull requests with artifacts such as screenshots or logs. Read the PR description, check files touched, run the same test commands locally on the branch when the change is risky. See /blog/how-cursor-cloud-agents-work-and-when-to-use-them.

Pre merge checklist

• Diff stays inside agreed scope
• You can explain every changed hunk
• Tests and lint you trust are green
• No secrets, tokens, or debug logging in the patch
• Migration or config steps documented if operators need them

Common mistakes

• Declaring done when only the happy path was exercised
• Letting Agent run broad destructive commands without reading them
• Accepting fixes that silence tests instead of correcting behavior
• Skipping local verification on cloud agent PRs because CI is green
• Forgetting to rerun tests after dismissing a few diff hunks manually

Verification with typecheck and build

Tests alone may miss type errors in typed projects. Add npm run build or npm run typecheck to done criteria when your team relies on them in CI.

Done when all pass:
npm test -- --testPathPattern=checkout
npm run typecheck
npm run build

Flaky tests after Agent changes

Ask Agent to run the flaky test multiple times when timing bugs are suspected. Combine with Debug mode if failures only appear under load. Do not merge when the test passes once but fails on retry without explanation.

Run npm test -- --testPathPattern=retry --runInBand five times.
Report pass fail counts.
If any fail, treat as blocking and diagnose before merge.

Document verification in the pull request

When Agent did the implementation, paste the commands you ran and their result into the pull request description. Future reviewers then know which checks passed on your machine. Cloud agent PRs should list the same commands the remote environment ran.

PR verification notes:
npm test -- --testPathPattern=checkout (pass)
npm run lint (pass)
Manual: verified double submit fixed on iOS Safari simulator

Regression checks after refactors

When Agent renamed symbols across many files, run the full test suite even if the scoped test passed. Scoped tests prove the happy path in one module but miss broken imports elsewhere. Add one integration test if Agent touched shared utilities that many features depend on.

Agent renamed formatDate in src/lib/dates.ts.
Run: npm test (full suite)
If slow, at minimum: npm test -- src/lib/dates src/features/
Add one test that imports formatDate from a consumer route.

If CI failed on a cloud agent pull request, reproduce locally with the same command CI logs show. Fix in Agent locally and push. Do not merge based on Agent claim that tests pass without seeing output.

Related: /blog/how-to-use-cursor-agent-to-build-and-refactor-code, /blog/how-to-debug-code-with-cursor, /blog/how-cursor-cloud-agents-work-and-when-to-use-them.