E2E Scenarios (Cypress / Playwright)

E2E tests are essential for validating critical user journeys but writing them is time-consuming and maintenance is often neglected. AI enables you to produce robust scripts quickly and maintain them as UI evolves. This guide presents the workflow that combines fast generation and best practices to avoid flaky tests.

Step-by-step Workflow

Describe the user journey

Step by step what the user does, with target selectors (ideally data-testid) if you have them. More precise = more robust test.

Generate the E2E scenario

Request Cypress or Playwright depending on your stack, with explicit expectations (waitFor, expect.toBeVisible) rather than arbitrary sleeps.

Refactor into page objects

For maintainability: Page Object Model pattern. AI can generate/refactor automatically. Drastically reduces long-term maintenance cost.

Add fixtures and mocks

E2E tests depending on APIs: have fixtures and mocks generated. Reproducible tests independent of external conditions.

Integrate into CI

GitHub Actions / GitLab CI / CircleCI pipeline with proper reporters (HTML, JUnit for integration). AI can generate the full config.

Copyable Prompts

Complete Playwright scenario

Generate a Playwright scenario (TypeScript) for this journey:nn**Journey**: [STEP-BY-STEP DESCRIPTION]n**Application**: [URL OR CONTEXT]n**Available selectors**: [LIST — ideally data-testid]n**Expectations**: [EXPECTED BEHAVIOR AT EACH STEP]nnConstraints:n- Page Object Model: create/use a page classn- Robust selectors (data-testid > ARIA roles > text > CSS)n- Explicit expectations with Playwright expect (toBeVisible, toHaveText, toHaveURL)n- No arbitrary sleeps, use waitFor / waitForLoadStaten- Fixtures for test datan- Cleanup in afterAlln- Imports and structure ready to paste into a Playwright projectnnProvide: (1) the page class, (2) the test, (3) the fixtures, (4) explanatory comment if needed.

Cypress → Playwright conversion

Convert this Cypress test to Playwright TypeScript:nn[CYPRESS TEST]nnKeep the same behavior but use Playwright best practices:n- expect with auto-retryn- Robust locators (getByRole, getByText, getByTestId)n- Async/await everywheren- Modern fixtures and test.beforeEachnnAlso provide the 3 main differences you had to handle.

Debugging a flaky test

This E2E test is flaky (fails 1 in 5 times):nn[TEST]nnIdentify likely causes and propose fixes:n1. **Fragile selectors**: replace with robust onesn2. **Race conditions**: timing between actions and assertionsn3. **External dependencies**: APIs, shared datan4. **Page state**: no waitFor for dynamic elementsn5. **Missing cleanup**: tests affecting each othernnProvide the corrected version + explanation of changes.

Recommended tools

Claude Code

★ 4.9 (92) · 20 USD/mois

Assistant de développement IA agentique par Anthropic : comprend votre codebase, édite des fichiers, exécute des commandes et s'intègre à votre environnement de développement.

Why : Excellent pour les tests E2E en contexte de repo : accès aux selectors, conventions du projet, structure de tests existante.

Try ↗Full review

🤖

Cursor

★ 4.8 (145) · 20 USD/mois

Éditeur de code IA révolutionnaire basé sur VS Code avec agents autonomes

Why : L'IDE permet de générer un test, le faire tourner, itérer sur les échecs en quelques minutes.

Try ↗Full review

Claude AI

★ 4.9 (55) · Gratuit

Assistant conversationnel d’Anthropic axé sécurité et contexte long. Excellent pour rédaction, analyse, résumés, code et agents. Interface claire, bons résultats en français.

Why : Pour les refactorings et la stratégie de tests à grande échelle (page objects, fixtures, CI).

Try ↗Full review

Estimated ROI

Time Saved

70-80% on E2E tests (30-60 min vs 2-4h)

Quality Gain

Robust tests (less flaky), systematic Page Object Model, easier maintenance

Cost

€20-30/month

Frequently asked questions

Are the generated E2E tests flaky?

If well-guided (robust selectors, explicit expectations, no sleeps): no. If you take raw output without reviewing: yes. Prompt quality makes the difference — always include anti-flakiness constraints explicitly.

Can you test on all browsers?

Playwright: yes, Chromium / Firefox / WebKit in parallel. Cypress: Chromium and Firefox stable, WebKit experimental. AI can generate multi-browser config in seconds.

E2E tests maintenance?

That's the hidden cost. With well-structured POM (Page Object Model): acceptable maintenance. Without it: nightmare. AI can enforce POM systematically and refactor in minutes what would take days.

Visual tests (visual regression)?

Dedicated tools (Percy, Chromatic, Argos) remain better than pure AI solutions. AI can help interpret diffs and identify real bugs vs intended changes.

← Back to guide QA / Test engineer

🔄 E2E Scenarios (Cypress / Playwright)