agentleFS
hzijadhzijad/playwright-agent-skills/skills/playwright-network-mocking/SKILL.md

playwright-network-mocking

Skill9 starsChanged 4 months agoMITView on GitHub

Playwright workflows for deterministic third-party responses using page.route().

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
  1. Distinctive:

    Use this skill when a test depends on a slow, unreliable, or external service and you need deterministic responses without hitting the real …

    line 10
  2. Distinctive:

    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 …

    line 12
  3. Distinctive:

    When a test depends on an unreliable or slow external API.

    line 16
  4. Distinctive:

    When you need deterministic responses for billing, email, auth, analytics, or similar services.

    line 17
  5. Distinctive:

    When you want to mock the minimum necessary surface area and leave the rest of the app untouched.

    line 18
  6. Distinctive:

    When the test must validate a real provider integration end to end.

    line 22
  7. Distinctive:

    When the login UI is the feature under test.

    line 23
  8. Very specific:

    When you are diagnosing a flaky test and should start with playwright-debugging instead.

    line 24
  9. Very specific:

    Use page.route() to replace external responses with deterministic data before the page makes the request.

    line 28
  10. Very specific:

    Prefer page.route() when the response is part of the behavior under test and must be controlled from the browser context.

    line 52
  11. Distinctive:

    Verify the intercepted request produces the expected UI and that the real service is not required for the test to pass.

    line 56
  12. Distinctive:

    Use trace viewer or UI mode to confirm the mocked response is the one the app consumed.

    line 64

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-debugging instead.

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.ts

Use trace viewer or UI mode to confirm the mocked response is the one the app consumed.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.