Playwright Network Assertion

Two things this does, often together: watch real network traffic and assert on it (status codes, duplicate calls, payload shape, calls to endpoints that shouldn't be hit), and mock traffic to synthesize states a live backend won't reliably produce on demand — a 500, a timeout, an empty result set, a dropped connection.

Relationship to the other skills

A scenario-mapper comprehensive-mode row like "payment API returns 500 mid-checkout" or a flow-runner negative-path step can't be executed against a real backend that's (hopefully) not actually broken right now — this skill is how those scenarios get run at all. If bug-triage traced a bug to a suspicious response ("looks like the 502 from /api/cart is what breaks the UI"), that's a correlation from a log until you mock that exact response deterministically and confirm the same symptom reproduces — that's the stronger form of evidence, and this skill is how you produce it.

Before you start

Same check as the rest of the toolkit, with a specific ask this time: does your tool support route interception — the MCP server's browser_route (or similarly named network-mocking tool — check your actual tool list, this is a newer addition and naming may vary by version) or, on @playwright/cli / raw Playwright, page.route() / context.route(). Passive observation (just watching traffic go by) is usually available even without full interception — check for a network-log or browser_network_requests-style tool if that's all a given check needs.

Core principles (and why)

Register mocks before the request fires, not after. A route handler set up after the app has already sent the request is too late — it'll just be real traffic. Set up interception before triggering whatever action causes the call (the button click, the page load), not as an afterthought once you notice the response looks wrong.

Know which of the three actions you actually want. Route interception generally gives you: fulfill (replace the response entirely with synthetic data), continue (pass through to the real server, optionally modifying the request/response), or abort (block it — simulating a dropped connection or network failure, not a normal HTTP error the app can parse). These are meaningfully different tests: "the API returns a 500" and "the network drops entirely" often exercise different error-handling code paths, and an app that handles one gracefully may not handle the other. Pick deliberately based on what you're actually trying to verify.

Scope your URL patterns as narrowly as the check needs. A broad pattern like matching everything under /api/ is convenient but risks silently intercepting calls you didn't mean to touch — an auth-refresh request, a different endpoint that happens to share a path prefix — which can break the rest of the flow in a confusing way that looks like an unrelated failure. Match the specific endpoint you're testing.