How to generate E2E tests with Cursor

You generate E2E tests in Cursor by letting the AI read your existing code (usually the UI, API routes, and expected user flows), then asking it to create real test files in your project’s actual testing framework. Cursor won’t run the tests for you — that’s still your local terminal — but it can generate the boilerplate, fill in selectors, mock data, and create full multi-file test suites. The workflow is: highlight code → ask Cursor to draft an E2E test → review the proposed diff → run it locally → iterate. That’s the whole loop.

 

What “E2E tests” means in practice

 

E2E (end‑to‑end) tests simulate a real user interacting with your application from the outside — usually clicking buttons, filling forms, waiting for API responses, etc. The most common real tools for this are Playwright and Cypress. These are Node.js‑based test runners that open a browser and verify your app behaves correctly.

Cursor can generate these tests, but it doesn’t magically know your routes or selectors unless you show it or let it read the relevant files.

 

The practical step‑by‑step workflow in Cursor

 

This is the workflow real developers use daily in Cursor:

• Open the component, page, or server route you want to test. The AI needs context.
• Select the relevant code (for example a React component or API handler).
• Open the AI Chat and ask something clear like “Generate a Playwright E2E test that covers the login flow shown in this component”.
• Cursor will propose a file creation diff (ex: tests/login.spec.ts).
• You review the diff — this is critical. AI can hallucinate selectors; you must verify them.
• Click Apply and run the tests in the integrated terminal: npx playwright test or npx cypress open.
• If something fails, highlight the failure and ask Cursor “Fix this test”.

 

Example: Asking Cursor to generate an E2E test (Playwright)

 

Let’s say your project uses Playwright and you have a login page at /login. You’d highlight the Login component and then ask Cursor: “Write a Playwright E2E test that verifies successful login”. Cursor normally produces something like this:

// tests/login.spec.ts
import { test, expect } from "@playwright/test";

test("user can log in", async ({ page }) => {
  await page.goto("http://localhost:3000/login");

  await page.fill("input[name='email']", "[email protected]");
  await page.fill("input[name='password']", "password123");

  await page.click("button[type='submit']");

  // This waits for navigation or success indicator
  await expect(page).toHaveURL("http://localhost:3000/dashboard");
});

 

Two important notes:

• Your selectors must be correct. Cursor often guesses. If your input is <input id="email">, update the selector to #email.
• You must verify URLs, element names, and API behavior. Cursor has no internal runtime to check your project’s reality.

 

How Cursor can help beyond basic generation

 

• Multi-file reasoning: You can tell Cursor “Generate E2E tests for all flows in the auth folder” and it will scan multiple files.
• Refactor selectors: You can ask it to replace flaky selectors with data-test-id attributes and modify your components accordingly.
• Explain failures: When Playwright or Cypress fails, paste the stack trace into Cursor — it will tell you where selectors or timing are wrong.
• Generate mock users or seed scripts: Cursor can produce setup files needed for tests.

 

Common mistakes juniors make with Cursor and E2E tests

 

• Letting Cursor invent selectors — always check your actual JSX or HTML.
• Not giving enough context — highlight relevant files so the AI sees them.
• Expecting AI to run tests — only your local terminal can run them.
• Trying to generate large test suites in one message — do it flow by flow.

 

A simple reliable workflow to train yourself

 

• Pick a single flow (login, signup, form submission).
• Show Cursor the component and the API endpoint.
• Ask for one E2E test file.
• Run it locally and fix selectors.
• Once working, ask Cursor: “Generate more tests using the same patterns.”

 

If you follow this workflow, Cursor becomes a powerful E2E test generator — not by magic, but by guiding it with your real code and verifying every diff like a senior engineer would.