🧪 AI Development, Part 6: How We Write E2E and API Tests with Cursor
🧠 AI Development: Table Of Content
- Part 1: The Moment It Became Real
- Part 2: Cursor — Your New Pair Programmer
- Part 3: Why Structure Matters — Introducing the RIPER Workflow
- Part 4: Teaching Cursor to Think — Memory Banks & Rule Files
- Part 5: RIPER in Action — Real Examples from Production
- Part 6: How We Write E2E and API Tests with Cursor
- Part 7: When Cursor Hallucinates — How We Keep It Grounded
- Part 8: What’s Next — Scaling AI Workflows Across Teams
“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
/researchmode - 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
/planAPI 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
| Situation | Best Strategy |
|---|---|
| Existing test coverage | Reference current tests |
| No prior tests | Use precise QA-style instructions |
| New features / no UI tests | Generate from story requirements + use Playwright MCP |
| API test | Reference 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.

