Request Modification

Introduction

Request Modification is a practical Playwright skill for SDETs who need to test modern apps with auth, network control, isolated sessions, and complex state. Instead of memorizing syntax, learn the production reason behind it: what risk it reduces, what evidence it gives, and how it changes the way a team ships software.

Purpose of this lesson

Story: A suite became 40 minutes faster after login moved to storage state and slow third-party calls were mocked at the network boundary. In this lesson, request modification tests headers, payloads, and edge cases. That is the difference between a test that merely runs and a test that helps a team decide.

Understanding the topic

Why this exists: Request modification tests headers, payloads, and edge cases. Advanced Playwright is about controlling the browser environment, not just observing it.

• Real problem solved: Request Modification reduces ambiguity when browser behavior, data, timing, or infrastructure changes.
• Production use: authenticated tests, SaaS dashboards, payment mocks, third-party outage scenarios, and multi-role workflows.
• Beginner misuse: Mocking everything until the tests no longer prove the real system works.
• Elite SDET move: Combine storage state, route interception, API setup, and context isolation without hiding critical integration risk.

Visual explanation

Mental model:

Context
  ├─ storageState
  ├─ routes / mocks
  ├─ permissions
  └─ pages
       ↓
Deterministic scenario

Informative example

A practical example for Request Modification:

await page.route("**/api/recommendations", async route => {
  await route.fulfill({ json: [{ id: "request-modification", title: "Stable item" }] });
});
await page.goto("/dashboard");
await expect(page.getByText("Stable item")).toBeVisible();

Execution workflow

Real-world use

In real teams, Request Modification matters because product code changes every week. The test must still tell a useful story: what user behavior was protected, what state was expected, what evidence was captured, and whether the failure belongs to the app, the test, the data, or the environment.

Best practices

• Use storageState for speed but regenerate it deliberately.
• Mock unstable dependencies, not the behavior you actually need confidence in.
• Keep route mocks close to the scenario they support.
• Validate important network responses when UI alone is not enough.

Common mistakes

• Using stale auth state and debugging fake product failures.
• Mocking the backend so heavily that contract drift goes unnoticed.
• Sharing context-level setup across unrelated roles.

Debugging tips

• Inspect trace network tab for mocked versus real calls.
• Log storage state age and user role when auth tests fail.
• If a mock is not applied, verify URL pattern and route order.

Advanced interview questions

Summary

Request Modification is valuable when it makes browser automation faster, clearer, and easier to debug under real product change.