End-to-End Test Automation

Your signup flow works perfectly when you test it manually. Then QA reports that users on Safari with autofill enabled cannot submit the form because the password validation fires before autofill completes. Your unit tests and integration tests never caught this because they do not run in a real browser. E2E tests exist to simulate what actual users do — and AI makes writing them dramatically faster.

What You’ll Walk Away With

• Workflows for generating Playwright tests from user stories and acceptance criteria
• Page Object Model generation that keeps E2E tests maintainable
• Visual regression testing integration for catching UI drift
• Strategies for handling authentication, dynamic content, and flaky tests
• Cross-browser and mobile viewport configuration patterns

From User Story to Test

The fastest path to E2E tests: translate your user stories directly into Playwright scripts.

Cursor

Generate Playwright E2E tests for this user story:

"As a registered user, I can purchase a subscription:
1. I log in with email and password
2. I navigate to the pricing page
3. I click 'Subscribe' on the Pro plan
4. I enter my credit card details
5. I see a success confirmation with my new plan name
6. My dashboard shows 'Pro' as my current plan"

Requirements:
- Use Page Object Model for each page (LoginPage, PricingPage, CheckoutPage, DashboardPage)
- Handle the Stripe Elements iframe for card input
- Use test credit card 4242424242424242
- Assert at each step, not just the final state
- Include proper waits (no arbitrary timeouts)
- Tag as @purchase for selective test running

Save page objects to /tests/e2e/pages/
Save the test to /tests/e2e/flows/purchase-subscription.spec.ts

Claude Code

claude "Create a complete Playwright E2E test for the subscription purchase flow.

User journey:
1. Login -> 2. Pricing page -> 3. Subscribe (Pro plan) -> 4. Stripe checkout -> 5. Success -> 6. Dashboard verification

Generate:
- /tests/e2e/pages/login.page.ts (Page Object)
- /tests/e2e/pages/pricing.page.ts
- /tests/e2e/pages/checkout.page.ts
- /tests/e2e/pages/dashboard.page.ts
- /tests/e2e/flows/purchase-subscription.spec.ts

Each page object should:
- Use data-testid selectors (not CSS classes)
- Include waitFor methods for dynamic content
- Expose actions as descriptive methods (login(), selectPlan(), enterCardDetails())

Run: npx playwright test --project=chromium purchase-subscription
Fix any issues found."

Codex

Generate E2E tests for the subscription purchase flow.
Read the application code to understand:
- Available routes and page structure
- Form field names and validation rules
- Authentication mechanism

Create Page Objects and test specs using Playwright.
Run the tests against the dev server.
Fix any failures and create a PR with the working tests.

Page Object Model Generation

AI excels at generating Page Objects because the pattern is highly structured.

Tip

Copy-paste prompt for Page Object generation:

Generate a Playwright Page Object for our user settings page.

The page is at /settings and has these sections:
- Profile: name (text input), email (text input, readonly), avatar (file upload)
- Notifications: email notifications (toggle), push notifications (toggle), weekly digest (checkbox)
- Security: change password (current + new + confirm fields), enable 2FA (button), active sessions (list)
- Danger zone: delete account (button with confirmation modal)

The Page Object should:
1. Use data-testid attributes for all selectors: data-testid="settings-name-input"
2. Include methods for each user action: updateName(), toggleEmailNotifications(), changePassword()
3. Include assertion helpers: expectNameToBe(), expectNotificationEnabled()
4. Handle the confirmation modal for delete account
5. Handle file upload for avatar
6. Wait for save confirmation after each change

Save as /tests/e2e/pages/settings.page.ts

Visual Regression Testing

Catch unexpected UI changes by comparing screenshots across test runs.

Tip

Copy-paste prompt for visual regression setup:

Add visual regression testing to our Playwright E2E suite:

1. Configure Playwright for screenshot comparison:
   - Threshold: 0.1% pixel difference (catch real changes, ignore anti-aliasing)
   - Store baselines in /tests/e2e/screenshots/baseline/
   - Store failures in /tests/e2e/screenshots/failures/ (gitignored)

2. Add visual snapshots to existing critical page tests:
   - Login page (empty state, with validation errors, loading state)
   - Dashboard (empty state, with data, mobile viewport)
   - Pricing page (all three plan cards, hover states)

3. Create a helper function: expectVisualMatch(page, 'snapshot-name')
   that handles viewport setting, animation disabling, and font loading waits.

4. Add npm scripts:
   - test:e2e:visual - run visual tests
   - test:e2e:update-snapshots - update baselines after intentional changes

Handle flaky sources: disable animations, wait for web fonts, mask dynamic content (dates, avatars).

Handling Authentication in Tests

Cursor

Create an authentication helper for our Playwright tests that:

1. Has a storageState approach:
   - A global setup that logs in once and saves the auth state
   - Tests reuse the saved state (no login per test = faster suite)
   - Different states for: regularUser, adminUser, unauthenticatedUser

2. Save to /tests/e2e/auth/global-setup.ts and /tests/e2e/auth/states/

3. Configure playwright.config.ts to use global setup
   and make auth states available via test fixtures

4. Show usage in a test:
   test('admin can access user management', async ({ adminPage }) => {
     // adminPage is already authenticated as admin
   })

Claude Code

claude "Create a Playwright authentication infrastructure:
- Global setup that creates auth state files for each user role
- Test fixtures that provide pre-authenticated browser contexts
- API-based login (faster than UI login) for state generation
Save auth helpers to /tests/e2e/auth/
Update playwright.config.ts to use global setup.
Show an example test using the admin fixture."

Codex

Set up Playwright authentication for E2E tests:
- Create global setup for auth state management
- Support multiple user roles (admin, user, guest)
- Use API login for speed (skip the UI)
- Create test fixtures for each role
- Update config and show usage example

Fixing Flaky Tests

Tip

Copy-paste prompt for fixing flaky E2E tests:

Our E2E test "user can filter products by category" fails intermittently.
The test is at /tests/e2e/flows/product-filtering.spec.ts.

Diagnose and fix the flakiness:
1. Read the test and identify all timing-dependent operations
2. Replace any page.waitForTimeout() with proper waitFor conditions
3. Add retry logic for network-dependent assertions
4. Ensure the test does not depend on data from other tests
5. Add proper loading state waits (wait for spinner to disappear, not for arbitrary time)
6. Check if the test works differently on fast vs slow machines

Common flaky patterns to check:
- Clicking before an element is clickable (still animating)
- Asserting on content that loads asynchronously
- Race condition between navigation and data loading
- Network requests that sometimes take longer than expected

Cross-Browser and Mobile Configuration

Tip

Copy-paste prompt for cross-browser E2E configuration:

Configure our Playwright project for cross-browser and mobile testing:

1. Projects in playwright.config.ts:
   - Desktop Chrome (1280x720)
   - Desktop Firefox (1280x720)
   - Desktop Safari/WebKit (1280x720)
   - Mobile Chrome (iPhone 14 viewport)
   - Mobile Safari (iPhone 14 viewport)

2. Tag tests by scope:
   - @critical: run on ALL browsers (login, checkout, core features)
   - @desktop: run on desktop browsers only
   - @mobile: run on mobile viewports only
   - Default: run on Chrome only

3. Configure CI to run:
   - @critical on all browsers for every PR
   - Full suite on all browsers nightly
   - Chrome-only for non-critical tests on PR

4. Create a test helper that adjusts interactions for mobile
   (tap vs. click, swipe for carousels, hamburger menu navigation)

When This Breaks

“E2E tests take 20 minutes and developers skip them.” Parallelize across multiple workers (Playwright supports this natively). Run only critical-path tests on every PR, full suite nightly. Use the --shard option in CI to distribute across multiple runners.

“Tests break every time the UI changes.” You are using fragile selectors. Switch to data-testid attributes that are stable across design changes. Ask the AI to “rewrite all selectors to use data-testid instead of CSS classes or text content.”

“Visual regression tests fail due to font rendering differences.” Different OS font rendering causes pixel differences. Use Docker containers for consistent rendering in CI. Set a higher comparison threshold (0.5%) or mask text-heavy areas.

“The AI cannot interact with third-party iframes (Stripe, reCAPTCHA).” Use test modes for third-party services. Stripe provides test mode with predictable behavior. For reCAPTCHA, use the site key that always passes in test environments.

What’s Next

Mobile Testing Native and cross-platform mobile testing patterns.

Accessibility Testing Automated WCAG compliance testing in E2E flows.

Performance Testing Load and performance testing your application.