playwright-network-mocking
Skill9 starsChanged 4 months agoMITView on GitHub
Playwright workflows for deterministic third-party responses using page.route().
In this repository3 other files it gives its agents.
- playwright-auth-stateSkill
- playwright-coreSkill
- playwright-debuggingSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this skill when a test depends on a slow, unreliable, or external service and you need deterministic responses without hitting the real …
- Distinctive: line 12
Do not use this skill when the real third-party integration is the feature under test, or when the app is already local and deterministic …
- Distinctive: line 16
When a test depends on an unreliable or slow external API.
- Distinctive: line 17
When you need deterministic responses for billing, email, auth, analytics, or similar services.
- Distinctive: line 18
When you want to mock the minimum necessary surface area and leave the rest of the app untouched.
- Distinctive: line 22
When the test must validate a real provider integration end to end.
- Distinctive: line 23
When the login UI is the feature under test.
- Very specific: line 24
When you are diagnosing a flaky test and should start with playwright-debugging instead.
- Very specific: line 28
Use page.route() to replace external responses with deterministic data before the page makes the request.
- Very specific: line 52
Prefer page.route() when the response is part of the behavior under test and must be controlled from the browser context.
- Distinctive: line 56
Verify the intercepted request produces the expected UI and that the real service is not required for the test to pass.
- Distinctive: line 64
Use trace viewer or UI mode to confirm the mocked response is the one the app consumed.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Playwright Network Mocking
Overview
Use this skill when a test depends on a slow, unreliable, or external service and you need deterministic responses without hitting the real provider. It lets you isolate the boundary that matters while keeping the rest of the application real.
Do not use this skill when the real third-party integration is the feature under test, or when the app is already local and deterministic without request interception.
When to Use
- When a test depends on an unreliable or slow external API.
- When you need deterministic responses for billing, email, auth, analytics, or similar services.
- When you want to mock the minimum necessary surface area and leave the rest of the app untouched.
When Not to Use
- When the test must validate a real provider integration end to end.
- When the login UI is the feature under test.
- When you are diagnosing a flaky test and should start with
playwright-debugginginstead.
Network Interception
Use page.route() to replace external responses with deterministic data before the page makes the request.
import { test, expect } from '@playwright/test';
test('shows premium dashboard when billing is active', async ({ page }) => {
await page.route('**/api/v1/billing/status', async route => {
await route.fulfill({
status: 200,
json: {
subscription: 'active',
plan: 'premium',
},
});
});
await page.goto('/dashboard');
await expect(page.getByRole('heading', { name: 'Welcome to Premium' })).toBeVisible();
});Intercept only the unstable boundary and leave the rest of the application real. If the code under test makes several external calls, mock the minimum necessary surface area.
Prefer page.route() when the response is part of the behavior under test and must be controlled from the browser context. If you need broader, suite-wide control, consider a fixture or a backend test double instead of scattering route handlers through individual tests.
Verification
Verify the intercepted request produces the expected UI and that the real service is not required for the test to pass.
Typical checks:
npx playwright test tests/dashboard.spec.tsUse trace viewer or UI mode to confirm the mocked response is the one the app consumed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

