Workflow:Getgauge Taiko Network Request Interception
| Knowledge Sources | |
|---|---|
| Domains | Browser_Automation, Network_Mocking, Test_Isolation |
| Last Updated | 2026-02-12 03:00 GMT |
Overview
End-to-end process for intercepting, blocking, redirecting, and mocking HTTP requests during browser automation using Taiko's intercept API and network handler.
Description
This workflow covers using Taiko's network interception capabilities to isolate tests from external dependencies. The intercept API leverages the Chrome DevTools Protocol Fetch domain to register URL-pattern-based handlers that can block requests entirely, redirect them to different URLs, return stubbed response data, or modify request/response payloads through custom handler functions. This enables testing against controlled data without requiring separate mock servers, and prevents flaky tests caused by third-party service availability.
Usage
Execute this workflow when you need to test web application behavior with controlled network responses, block analytics or tracking scripts during testing, redirect API calls to test instances, or simulate error conditions and edge cases by returning custom response data.
Execution Steps
Step 1: Open Browser and Configure Interception
Launch the browser and set up network interception rules before navigating to the page under test. Interception rules are registered using the `intercept` API which accepts URL patterns and handler specifications. Rules should be registered before navigation to ensure they capture all requests from the initial page load.
Key considerations:
- Register intercept rules before calling `goto` to catch requests during page load
- Multiple intercept rules can be active simultaneously for different URL patterns
- URL matching supports exact URLs and pattern matching
Step 2: Block Unwanted Requests
Use the intercept API with just a URL pattern (no handler) to block requests entirely. Blocked requests are silently prevented from reaching the network, which is useful for eliminating analytics scripts, advertising resources, or other third-party calls that slow down or interfere with tests.
Key considerations:
- `intercept("https://www.google-analytics.com/analytics.js")` blocks a specific script
- Blocking reduces network traffic and speeds up test execution
- Blocked requests do not generate errors in the browser console by default
Step 3: Redirect Requests
Use the intercept API with a URL pattern and a replacement URL string to redirect requests from production endpoints to test instances. The browser transparently receives responses from the redirected URL while the page code believes it is communicating with the original endpoint.
Key considerations:
- `intercept("https://api.production.com", "https://api.test.com")` redirects all requests
- Redirects are transparent to the page JavaScript
- Useful for pointing API calls to staging or mock servers without modifying application code
Step 4: Stub Responses with Static Data
Use the intercept API with a URL pattern and a JavaScript object or string to return static response data. The intercepted request never reaches the network; instead, Taiko returns the provided data as the response body. This enables testing with deterministic data sets.
Key considerations:
- `intercept("https://api.example.com/data", {"users": [{"name": "Test"}]})` returns JSON
- The response content type is inferred from the data type
- Static stubs are ideal for deterministic testing of data-driven UI components
- Works for both XHR/fetch requests and resource loading
Step 5: Modify Requests with Handler Functions
Use the intercept API with a URL pattern and a callback function for dynamic request manipulation. The handler receives the request object and can modify headers, body, or URL before continuing the request, or can return a completely custom response. This provides the most flexibility for complex test scenarios.
Key considerations:
- The handler receives a request object with `continue`, `respond`, and `abort` methods
- `request.continue({headers: {...}})` forwards the request with modified parameters
- `request.respond({body: "...", headers: {...}})` returns a fully custom response
- Handlers execute for every matching request, enabling stateful mock behavior
Step 6: Clear Intercepts and Verify
After testing with intercepted network conditions, clear specific or all intercept rules using the `clearIntercept` API. Navigate to verify that the application behaves correctly with the intercepted data, then clean up interception state to avoid affecting subsequent tests.
Key considerations:
- `clearIntercept("https://api.example.com/data")` removes a specific intercept rule
- Always clear intercepts between test scenarios to prevent cross-contamination
- Use assertions to verify the page rendered correctly with the intercepted data
- Network throttling via `emulateNetwork` is a separate feature from request interception