Principle:Microsoft Playwright Identify Interception Targets
| Knowledge Sources | |
|---|---|
| Domains | Network_Testing, Mocking, Traffic_Analysis |
| Last Updated | 2026-02-11 00:00 GMT |
Overview
Monitoring network traffic to identify which requests and responses to intercept for mocking or modification.
Description
Before any network interception or mocking can take place, a test engineer must first observe and understand the network traffic that flows between the browser and external services. Identify Interception Targets is the foundational principle of deciding which HTTP requests and responses warrant interception, modification, or replacement in a test environment.
This principle operates at the observation layer: the test harness subscribes to network lifecycle events (request initiated, response received, request failed, request finished) and inspects properties such as URL, HTTP method, resource type, headers, and payload. By analyzing this traffic, the engineer builds a mental model of the application's network dependencies and can then decide which calls to mock, which to let pass through, and which to assert upon.
The key considerations when identifying interception targets include:
- URL patterns: Which API endpoints or third-party services does the application call?
- Resource types: Are we interested in XHR/fetch calls, document navigations, images, scripts, or stylesheets?
- Request methods: Should we intercept only GET requests for data fetching, or also POST/PUT/DELETE for mutation operations?
- Timing: At what point in the page lifecycle do these requests fire?
- Frequency: Are there polling requests or one-time fetches?
This principle is library-agnostic. Whether using Playwright, Puppeteer, Cypress, or a manual proxy, the fundamental task is the same: observe, categorize, and select network traffic for interception.
Usage
Apply this principle at the beginning of test development when:
- You are writing tests for a page that depends on backend APIs and need to understand which endpoints are called.
- You need to identify third-party service calls (analytics, ads, CDN) that may cause flakiness or slowness in tests.
- You want to categorize requests by type to decide which ones to mock (API calls) versus which to allow through (static assets).
- You are debugging a failing test and need to inspect what network requests are actually being made.
- You are planning a network mocking strategy for an entire test suite and need a comprehensive inventory of network dependencies.
Theoretical Basis
Network traffic observation follows the observer pattern: the test harness registers event listeners on the browser's network layer, and the browser emits events as requests flow through its networking stack.
The typical lifecycle of a network request from the observer's perspective:
1. REQUEST_INITIATED -> Observer receives request metadata (URL, method, headers, body)
2. RESPONSE_RECEIVED -> Observer receives response metadata (status, headers) and body
3. REQUEST_FINISHED -> Observer is notified that the full response has been consumed
OR
3. REQUEST_FAILED -> Observer is notified of a network error
A pseudocode example of traffic observation:
// Subscribe to all network events
browser.onNetworkRequest(request => {
log("Request:", request.url, request.method, request.resourceType)
if (shouldIntercept(request)) {
markAsInterceptionTarget(request.url)
}
})
browser.onNetworkResponse(response => {
log("Response:", response.url, response.status, response.headers)
analyzeResponseForMocking(response)
})
browser.onNetworkFailure(request => {
log("Failed:", request.url, request.failureReason)
// Failed requests may indicate external dependencies to mock
})
The decision of what to intercept typically follows these heuristics:
- Mock API calls: Requests to the application's own backend that return dynamic data.
- Block third-party: Requests to external services that slow down tests or introduce non-determinism.
- Pass through static assets: Requests for CSS, JS bundles, and images that are served locally or from a test server.
- Monitor navigation: Document requests that trigger full page loads.
This analysis phase produces an interception manifest -- a mapping of URL patterns to intended actions (mock, block, passthrough, assert) -- that guides the implementation of route handlers and response fixtures.