Generating Tests with Cursor

Cursor reads your code and generates tests that match your existing patterns. It examines your test files to learn which framework you use, how you structure tests, what mocking approach you prefer, and how you name test cases. The generated tests fit with what you already have.

More importantly, Cursor can run tests via the terminal and iterate on failures. Generate tests, run them, fix what breaks, run again. This closed loop produces tests that actually work.

Generating tests for existing code

When specifying what to test, be explicit about the cases that matter:

Cursor pulls from your existing tests to match patterns. If you have well-structured test files, the generated tests will follow the same structure, mocking strategies, and naming conventions.

Testing code you did not write

Test generation is useful for understanding unfamiliar code, not just code you wrote yourself. When working with legacy systems or third-party integrations, generating tests forces Cursor to figure out how the code works, including internal APIs and undocumented behavior.

The tests become executable documentation. If you are inheriting a codebase or working with code from another team, this approach helps you verify your understanding before making changes.

Tests as a safety net for refactoring

Before refactoring, generate tests that lock in current behavior. This gives you confidence that your changes do not break anything.

Run these tests after each refactoring step to catch regressions immediately. The tests define what the code should do; as long as they pass, you know the refactoring is safe.

The run-and-fix loop

Enable Auto-run to let Cursor execute tests automatically. When tests fail, Cursor reads the output and fixes them:

This is faster than reviewing generated tests manually. A test might have an incorrect assertion or miss a setup step. Rather than guessing what is wrong, let Cursor run the tests and learn from the actual failures.

Tests from requirements

Generate tests directly from acceptance criteria, tickets, or specs. This workflow starts with requirements rather than implementation.

With MCP integrations, you can pull requirements directly from Jira or other systems and generate tests without copy-pasting. This creates a workflow where tickets become tests before they become code.

Matching your testing patterns

Use rules files to specify your testing conventions so generated tests are consistent with your codebase.

Create a .cursor/rules/testing.mdc file:

# Testing Conventions## Framework- Use Jest with React Testing Library for frontend- Use pytest with fixtures for backend- Mock external services, never make real API calls in tests## Structure- One test file per source file, named *.test.ts or *_test.py- Group tests with describe blocks by method or behavior- Use arrange-act-assert pattern## Examples to follow- src/services/__tests__/AuthService.test.ts (good example of service tests)- src/components/__tests__/Button.test.tsx (good example of component tests)

The "Examples to follow" section matters most. When Cursor encounters an ambiguous decision, it looks at these files to see how you have handled similar situations.

Integration and E2E tests

Beyond unit tests, Cursor generates integration and end-to-end tests across frameworks: Playwright, Cypress, Selenium, pytest, Jest, and others. Specify your framework in your rules file.

For E2E testing, add rules that specify your automation framework, file locations, and conventions like the page object pattern or test data fixtures.

QA automation workflows

QA teams use Cursor for test automation beyond what developers typically write. This includes building out regression suites, creating test data generators, and automating manual test cases.

For QA-specific workflows, create rules files that specify your automation standards, test environments, and reporting requirements.

Requiring tests in code review

Use Bugbot to flag PRs that modify code without adding tests:

If the PR modifies files in {server/**, api/**, backend/**} and there are no changes in {**/*.test.*, **/__tests__/**, tests/**}, then:- Add a blocking Bug titled "Missing tests for backend changes"- Body: "This PR modifies backend code but includes no accompanying tests."- Apply label "quality"

This catches missing tests at the source rather than discovering gaps later.

Fixing failing tests in CI

The Cursor CLI can automatically fix CI failures, including test failures. See Fix CI Failures for a GitHub Actions workflow that analyzes failures, makes targeted fixes, and creates a fix branch.

Getting started

1. Start with one file. Pick a file with low coverage and ask Cursor to generate tests. Review what it produces. Does it match your patterns?

2. Create a testing rules file. Document your framework, conventions, and point to good examples. This pays off across every test Cursor generates.

3. Use the run-and-fix loop. Enable Auto-run and let Cursor iterate on failures. This produces tests that actually work.

4. Review generated tests. Verify they are testing the right things. Check that assertions are meaningful and edge cases are covered.

5. Add Bugbot rules. Use Bugbot to require tests for code changes so coverage does not slip.