Network interception
Intercept matching browser requests: mock a response, block a third party, or let it through and read what came back.
- Routing Answer a request without a server
- Blocking Drop what you did not come to test
- Observing Wait for the response, not for a delay
Routing
Answer a request without a server
Match a URL pattern and fulfil it from the test. The scenario can exercise a browser state without depending on a live test backend for that response.
Mock an API response →$page->route('**/api/orders', function ($route) {
$route->fulfill([
'contentType' => 'application/json',
'body' => json_encode(['orders' => []]),
]);
});
Blocking
Drop what you did not come to test
Analytics, chat widgets, ad tags. Abort matching requests when a third party is outside the scenario and would only add external noise.
Block unwanted requests →
Observing
Wait for the response, not for a delay
Requests and responses are events you can await and inspect: status, headers, body. Assert on the exchange the page actually made.
Wait for a network response →
Next step
Move from the tour to working code.
Choose the explanation, recipe, or runnable example that matches what you need next.
Common questions
Before you wire it into a suite.
Is routing only for mocks?
No. Routing can mock, modify, block, or continue requests. It is useful for fixtures, third-party noise, fault injection, and precise network assertions.
Where do headers and proxies fit?
Use context options for broad headers or proxy behavior, and route handlers for per-request decisions. Keep global network policy separate from scenario-specific mocks.
Should I test the real backend or mock it?
Use the real backend when integration is the subject. Mock when the UI state is the subject and the backend would only add cost or flakiness.