Writing Unit Tests in Cursor Without Letting It Guess
Cursor can draft a test file fast, but unverified tests are worse than none. A three-step loop keeps them honest.
Cursor's inline 'generate tests for this function' is a great first draft, but it loves to assert the implementation rather than the behavior. I always read the first generated test and ask 'does this fail if the function is wrong, or just if it changes?' Only the first kind is worth keeping.
The loop I use: ask for tests, run them, then deliberately break the function and confirm a test catches it. If nothing breaks, the test is a tautology and I tell Cursor to rewrite it against the contract, not the code.
Point it at the existing test style in the repo. Cursor matches patterns if you show it one example, and a test file that ignores your framework's conventions gets rejected in review anyway. Consistency is a prompt, not an afterthought.
Treat generated tests as a skeleton you own. The fastest path to a green suite is editing Cursor's draft with the cases you actually care about, not accepting the happy-path coverage it defaults to.