Module A-1·40 min read

Playwright (Primary), Cypress (Comparison), authentication flows, network interception, flaky test prevention, and CI-friendly test architecture.

JJS

Written by Jatin Jain Saraf · Senior Software Engineer

Module 5 — End-to-End Testing

Q: A QA engineer notices that their Playwright test suite for an e-commerce platform takes 45 minutes to run. Upon investigation, they realize that 30 minutes of that time is spent navigating to the login page, typing the username and password, and waiting for the dashboard to load at the beginning of *every single test case*. What is the standard architectural fix for this performance bottleneck in Playwright?

Create a `global-setup.js` script to log in once via the UI, save the authentication state (cookies/tokens) to a JSON file, and instruct Playwright to load that state before running the rest of the tests. — Logging in via the UI before every E2E test is a massive anti-pattern that destroys test suite performance. The solution is to extract the login flow into a global setup routine. Playwright can execute this routine once, capture the resulting browser context state (which includes cookies and localStorage where session tokens reside), and save it to disk. All subsequent tests can then be launched using this saved state, allowing them to start fully authenticated and instantly bypass the login screen.

Q: An E2E test designed to click a "Submit" button occasionally fails with a `TimeoutError: Element not found`. The developer tries to fix it by adding `await page.waitForTimeout(5000);` right before the click command. The test now passes consistently but takes 5 seconds longer to run. Why is this considered a bad practice, and what is the proper Playwright solution?

Hardcoded sleep delays make tests artificially slow and remain vulnerable to flakiness if the network takes 5.1 seconds. The correct solution is to rely on Playwright's built-in auto-waiting, or explicitly wait for a specific DOM state (e.g., `await expect(locator).toBeVisible()`) or network response. — Hardcoded delays (sleeps) are the root cause of slow and flaky E2E test suites. If you wait 5 seconds, your test is always penalized by 5 seconds, even if the element was ready in 200ms. Conversely, if the server is under heavy load and takes 6 seconds, the test will still fail. Modern frameworks like Playwright feature "auto-waiting"—they automatically wait for an element to be visible, stable, and actionable before interacting with it. If explicit waiting is needed, you should wait for the specific condition to be met (a network request completing or an element appearing) rather than an arbitrary tick of the clock.

Q: As an application grows, a team ends up with 300 Playwright tests. They notice that whenever the frontend developers change the CSS class or ID of the "Add to Cart" button, 45 different test files break and must be manually updated. Which architectural pattern should the team implement to prevent this maintenance nightmare?

The Page Object Model (POM) — The Page Object Model (POM) is an essential design pattern for large E2E test suites. It separates the test logic (assertions and flow) from the page structure (locators and DOM interactions). Instead of hardcoding `page.locator('#add-to-cart')` in 45 different tests, you create a `ProductPage` class with an `addToCart()` method. All 45 tests call that method. When the UI changes, you only update the locator inside the `ProductPage` class, and all tests instantly inherit the fix. This drastically reduces maintenance overhead.

Who this is for: Full-stack and QA engineers responsible for the final safety net of an application. End-to-End (E2E) testing guarantees that all your distinct components—frontend, backend, database, and third-party APIs—work together seamlessly from the user's perspective.

Learning Objectives

By the end of this module, you will be able to:

Understand the dominance of Playwright in the modern E2E landscape
Write resilient Playwright tests that simulate user flows
Handle asynchronous network behavior and intercept requests
Prevent flaky tests using auto-waiting strategies
Execute tests across multiple browsers seamlessly
Structure an enterprise-grade, CI-friendly test architecture

Playwright (Primary) vs. Cypress

Historically, Selenium dominated E2E testing. Then Cypress revolutionized the developer experience. Today, Playwright (built by Microsoft) is the industry standard due to its speed, true multi-browser support, and lack of iframe-based architectural limitations.

While Cypress remains excellent (and you will see it in many legacy codebases), we focus on Playwright because it represents the modern, future-proof approach to E2E testing.

Playwright Fundamentals

Playwright scripts look remarkably like standard async JavaScript. It launches an actual browser (Chromium, Firefox, or WebKit), navigates to your app, and interacts with the DOM.

Setup

bash

npm init playwright@latest

A Basic Playwright Test

Notice how clean the async/await syntax is. Playwright features built-in auto-waiting. It waits for elements to become visible, enabled, and stable before clicking them—virtually eliminating the need for setTimeout() hacks that plague older E2E frameworks.

javascript

import { test, expect } from '@playwright/test';

test('user can add item to cart', async ({ page }) => {
  // Navigate to the app
  await page.goto('https://mystore.com');

  // Find an element and interact
  await page.locator('text=Smartphone').click();
  await page.locator('button:has-text("Add to Cart")').click();

  // Assert the cart badge updated
  const cartBadge = page.locator('.cart-count');
  await expect(cartBadge).toHaveText('1');
});

Authentication Flows & Bypass

Logging in via the UI before every E2E test is a massive anti-pattern. It makes your test suite painfully slow.

Instead, log in once via the UI, save the authentication state (cookies/local storage), and reuse it across all subsequent tests. Playwright supports this natively.

javascript

// global-setup.js
import { chromium } from '@playwright/test';

export default async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  
  await page.goto('https://mystore.com/login');
  await page.fill('#user', 'admin');
  await page.fill('#pass', 'secret');
  await page.click('#submit');
  
  // Save the auth state to a JSON file!
  await page.context().storageState({ path: 'state.json' });
  await browser.close();
};

You then configure Playwright to load state.json before every test, bypassing the login screen entirely.

Network Interception

E2E tests interact with real APIs. But what if you want to test how your UI handles a 500 Internal Server Error from Stripe? You can't ask Stripe to fail.

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

javascript

test('displays error boundary on payment failure', async ({ page }) => {
  // Intercept the /api/pay endpoint and force a 500 response
  await page.route('**/api/pay', route => {
    route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ error: 'Gateway Timeout' })
    });
  });

  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:

Never use page.waitForTimeout(3000). Always wait for a specific DOM state (await expect(locator).toBeVisible()) or network response (await page.waitForResponse()).
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' })).
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.

javascript

// pages/LoginPage.js
exports.LoginPage = 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:

javascript

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

text

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.

Knowledge Check

A QA engineer notices that their Playwright test suite for an e-commerce platform takes 45 minutes to run. Upon investigation, they realize that 30 minutes of that time is spent navigating to the login page, typing the username and password, and waiting for the dashboard to load at the beginning of *every single test case*. What is the standard architectural fix for this performance bottleneck in Playwright?

An E2E test designed to click a "Submit" button occasionally fails with a TimeoutError: Element not found. The developer tries to fix it by adding await page.waitForTimeout(5000); right before the click command. The test now passes consistently but takes 5 seconds longer to run. Why is this considered a bad practice, and what is the proper Playwright solution?

As an application grows, a team ends up with 300 Playwright tests. They notice that whenever the frontend developers change the CSS class or ID of the "Add to Cart" button, 45 different test files break and must be manually updated. Which architectural pattern should the team implement to prevent this maintenance nightmare?

Test your knowledge with more question sets

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 →

Sign in to keep reading

The rest of this module is free — sign in with Google to unlock it and track your progress.

PreviousModule P-3: BDD with Cucumber Next Module A-2: CI/CD & Quality Gates

Discussion

Join the discussion

Loading comments...