Module 5 — End-to-End Testing

Instead, you intercept the network request directly in the browser and mock the response.

test('displays error boundary on payment failure', async ({ page }) => {
  // Intercept the /api/pay endpoint and force a 500 response
  await page.route('**/api/pay', async route => {
    await route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ error: 'Internal Server Error' })
    });
  });
 
  await page.goto('/checkout');
  await page.click('button#pay-now');
 
  // Verify the UI responds gracefully to the mocked failure
  await expect(page.locator('.error-banner')).toBeVisible();
});

---

Flaky Test Prevention

A test that passes 90% of the time and fails 10% of the time is a "flaky" test. Flaky tests destroy trust in your CI pipeline.

Rules for preventing flakes in E2E:

1. Never use page.waitForTimeout(3000). Always wait for a specific DOM state (await expect(locator).toBeVisible()) or network response (await page.waitForResponse()).
2. Use resilient locators. Don't select elements by brittle CSS classes (.btn-blue-5). Select them by user-facing text, ARIA roles, or data-testid attributes (page.getByRole('button', { name: 'Submit' })).
3. Isolate state. Tests should not depend on each other. Test B should pass even if Test A is deleted.

---

Real-World Test Architecture

If you dump 500 tests into a single folder, your test suite will become unmaintainable. An enterprise-grade architecture requires structure.

The Page Object Model (POM)

The POM pattern separates test logic from page structure. Instead of scattering .locator('#login-btn') across 50 tests, you encapsulate it in a class.

// pages/LoginPage.js
export class LoginPage {
  constructor(page) {
    this.page = page;
    this.emailInput = page.locator('#email');
    this.submitBtn = page.getByRole('button', { name: 'Log in' });
  }
 
  async login(email, password) {
    await this.emailInput.fill(email);
    await this.page.fill('#password', password); // inline locator for brevity
    await this.submitBtn.click();
  }
}

Now, your test becomes highly readable:

import { test } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';
 
test('user login', async ({ page }) => {
  const loginPage = new LoginPage(page);
  await page.goto('/login');
  await loginPage.login('test@user.com', 'password123');
});

If the ID of the login button changes, you only update the LoginPage class, not 50 different test files.

Recommended Folder Structure

e2e/
├── config/              # Environment vars (staging vs prod)
├── data/                # Mock JSON responses and test user credentials
├── pages/               # Page Object Models (POMs)
├── specs/               # The actual test files
│   ├── auth.spec.js
│   └── checkout.spec.js
└── utils/               # Setup scripts, global auth routines

---

Key Takeaways

• Playwright is the modern standard for E2E testing, offering cross-browser support and auto-waiting.
• Auto-waiting drastically reduces the flakiness common in older E2E tools.
• Authenticating via the UI before every test is an anti-pattern; state should be saved and reused.
• Network interception allows you to test edge cases like server failures.
• The Page Object Model (POM) is essential for maintaining large test suites.

---

---

We have now covered Unit, Integration, and E2E testing. The final piece of the puzzle is automation. In the next module, we will learn how to block bad code from ever reaching production using CI/CD pipelines.

Next: Module 6 — CI/CD & Quality Gates