Cursor for QA Engineers: Tests, Coverage and Repros

Point Cursor at the code under test and most of the role opens up. It will draft a first suite for a module and push past the happy path into the boundary and error cases people skip. Hand it a bug report and you get back a failing test that reproduces it. The work that matters most is the last item on the list below: reading generated code for the risks a quick glance misses.

• Generate tests for a module, then refine the cases.
• Repro bugs by writing a failing test from a report.
• Expand coverage by asking for boundary and error-path cases.
• Review risk in AI-generated code (auth, data handling, edge cases).

Those four sit in rough order of how cheap they are to get wrong, though the ordering is mine rather than Cursor's. A thin generated suite announces itself eventually, when something breaks in production and nothing went red.

Reviewing generated code for risk is the expensive end, mostly a question of volume. Code arrives faster than it used to, review capacity did not move, and the careful read of the auth path is what gets dropped in between.

A generated test that passes on its first run has told you nothing. The habit that earns trust is watching each test fail before the fix and pass after, so you know it's actually touching the code. The rest of it (a testing rule for style, an explicit ask for error paths, a read of what each test asserts) keeps the green checkmarks honest.

• Confirm each test fails before the fix and passes after (no tautologies).
• Add a testing rule so generated tests match your framework and style.
• Ask explicitly for edge cases and error paths, not just the happy path.
• Keep a human in the loop. Review what the tests actually assert.

Watching a test fail is the only one of those four you cannot delegate, which is why it sits at the top. The other three raise the odds of getting a good test; this is the one that tells you whether you got one. A suite that has only ever been green is compatible with almost any state of the code underneath it, including the state where the assertion sits inside a try block that quietly swallows the failure.

The cost of getting this wrong is one bad test, or that is how it looks the first time. What it actually costs is the next green run, which now gets read by hand because nobody trusts the last one, and reading a suite by hand is the work the generation was supposed to remove. Spend the extra minute on the first test in a batch rather than on the tenth.

If a rule is not being obeyed, work out whether it is loading at all before you rewrite it. Project rules only count when the file carries the .mdc extension, and the frontmatter has to match how you meant it to apply: a globs pattern that really matches your test paths, or a description if you are leaning on the agent to pull the rule in. Cursor's own best-practice list also says keep a rule under 500 lines and reference your canonical test file rather than pasting it in. The rules-not-following page has the rest of the checklist.

One piece of the standard rules advice does not transfer here. Cursor says to start simple and add a rule only after you have watched the agent make the same mistake repeatedly, which is good discipline for most work. Test conventions are the exception I would make up front: they are cheap to write down, and the mistake you are heading off is one you may not notice for a month.

Wrap it in a skill. A "test coverage" skill holds instructions for both backend and frontend coverage, runs an underlying coverage.sh (a pytest-coverage command), then formats and outputs the report, including an HTML report.

Less than a full setup list suggests, with one exception. On a small team you can hold in your head which tests actually assert something, and a rule file plus one coverage skill covers most of the rest. The exception is the fail-first check, which does not get cheaper when there are fewer people around to catch it.

The calculation changes once the people writing tests and the people trusting them are different people. A convention you can explain in a stand-up will not survive three teams, so it has to live where the agent reads it, which is what the rule file is for. On Team and Enterprise plans it can also be a Team Rule that an admin marks as required rather than something individuals switch off in Customize.

None of it decides what correct means. Somebody still has to state the expected output before a test can check for it, and that judgment does not get cheaper with more agents running. On a two-person team the person who does it is obvious. Once there are several teams it tends to end up unowned, usually because everyone assumes the suite already covers it.

Yes. Type @browser in a prompt and Cursor runs your built app in a browser pane inside the Agents window. Beyond viewing, you can hand it the controls: "test that the category slider works, take control and make sure it works." It scrolls, clicks and moves sliders on its own. The field team says this in-browser agent QA is how a lot of folks do QA at Cursor.

Use plan mode to do the thinking before any edits. One prompt can carry the whole sequence: "find all my FIXME and TODO comments, determine the top five most critical, create a detailed testing plan to keep behavior consistent, then migrate to the new functionality while making sure nothing else breaks." Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. returns a Markdown plan with P0-P2 items, each with a problem statement and a per-item unit-test plan.

Two more patterns worth knowing. For accessibility, the requirements doc is the test spec: put your standard a11y requirements in a Markdown file and ask the agent to run through them and verify each one is present. A large insurance customer used exactly this pattern to audit one of their UI products. No special tooling needed.