4 min read

🧪 AI Development, Part 6: How We Write E2E and API Tests with Cursor

“It’s like talking to a child — the more specific you are, the better the result.”
— Romario Nijim

Testing is where most AI-powered dev tools fall short. Sure, they can generate some expect() statements — but useful, maintainable, standards-compliant tests? That’s another level.

At GrowthSpace, we’ve built a workflow with Cursor + RIPER that reliably generates E2E and API tests — not just code, but test plans, business logic, and repeatable structure.

In this post, we’ll break down how we do it.


🧪 E2E Testing with Cursor

There’s more than one way to generate end-to-end tests with AI. We found three that work well, depending on the situation.


🧭 1. Reference Existing Tests

“Cursor, look at the tests for program creation — now write one for X.”

When you already have tests in the repo:

  • Start in /research mode
  • Ask Cursor to analyze the test structure
  • Prompt it to plan a new test based on an adjacent flow

✅ Example prompt:

/plan a regression E2E test that creates a participant-led program, validates it was created, adds a participant, and checks they appear in the participants tab.

Once the plan looks good, move to /execute and let Cursor generate the test file. You’ll still need to review and tweak selectors or edge cases.


✍️ 2. Precise STD-Style Instructions

“Talk to Cursor like it’s QA following your steps.”

This method works best when you don’t have existing test scaffolding.

  • Write your prompt like a QA test doc
  • Include steps like: navigate, click, fill, submit
  • Cursor will follow the structure exactly

✅ Example prompt:

/plan a test that:
1. Logs in as a mentor
2. Navigates to Programs
3. Clicks “Create Program”
4. Fills in all required fields
5. Submits and checks for a success notification
💡 Romario’s tip: “This is the most reliable method. Be painfully specific.”

🧠 3. Generate from Story Requirements

“Give Cursor the business requirements — let it extract the tests.”

This is the most autonomous method:

  • Paste in story or feature requirements
  • Let Cursor extract test cases
  • Review the plan
  • Ask it to write tests for the critical scenarios

You can enhance accuracy by:

  • Pointing Cursor to relevant code (@src/app/forms)
  • Referencing memory bank entries for testing rules

🔍 Bonus: Using Playwright’s MCP Server

Cursor can integrate with Playwright’s MCP (Model Context Protocol) server, which allows it to:

  • Navigate the browser
  • Inspect DOM structure
  • Extract locators
  • Understand live UI behavior
“It’s like giving Cursor a robot mouse and saying: ‘go explore this new page.’”

This is especially useful when generating tests for new UI features that don’t yet exist in the test suite.


🔐 API Test Generation

Generating API tests is similar, but follows a slightly different process.


🔁 1. Let Cursor Research the Microservice

  • Start in /research
  • Ask it to analyze the target microservice
  • Then /plan API tests based on endpoints it finds

✅ Example prompt:

/plan API tests for the Coaches microservice, using our internal API test rules.

If you have a memory bank entry for api-test-rules.md, reference it or include a pointer in projectbrief.md.


📁 2. Explicit File-Based Referencing

You can directly point Cursor to the service code:

@microservices/coaches/ — look here and generate security, business logic, and validation tests.

Cursor will output a structured test plan like:

  • ✅ Security Tests
  • ✅ Business Logic Tests
  • ✅ Parameter Validation Tests

Once approved, move to /execute and let it generate the files.


🧠 TL;DR — What Works Best

SituationBest Strategy
Existing test coverageReference current tests
No prior testsUse precise QA-style instructions
New features / no UI testsGenerate from story requirements + use Playwright MCP
API testReference service + memory bank rules

🧠 A Final Thought from Romario:

“Cursor is amazing at boilerplate. But you need to teach it the rules — just like a junior dev.”

With RIPER, memory banks, and precision prompts, we now generate tests with fewer mistakes, better structure, and faster iteration — all with Cursor doing 80–90% of the heavy lifting.


Coming Next: What Happens When It Goes Off the Rails

In the next post, we’ll show you:

  • Real hallucination examples
  • Times Cursor changed too much or misunderstood the request
  • How we caught it
  • Tips to stay in control
Until then, try this:
Open Cursor and ask:
/plan an API test for our login endpoint that validates user input, handles invalid credentials, and checks for correct tokens.

Let us know what it generates — and if it made the same mistakes you used to.

⚠️ AI Development, Part 7: When Cursor Hallucinates — How We Keep It Grounded
“It’s still like a junior dev — you have to check everything.” AI pair programming is fast, powerful, and surprisingly creative. But just like an overconfident intern, it can also go completely off the rails. In this post, we’ll talk about: * Real examples of hallucinations from Cursor * What we’