Principle:Getgauge Taiko Request Blocking
Overview
Request Blocking is the technique for preventing specific HTTP requests from completing by failing them at the browser level during automated testing with Taiko.
Description
Request blocking prevents specified URLs from loading by responding with an immediate network failure. When an interceptor is registered without an action parameter, any matching request is failed using the CDP Fetch.failRequest method with an error reason of "Failed". The request never reaches the network — the browser receives an immediate failure response as if the network were unreachable for that specific URL.
This technique is valuable for several testing scenarios:
- Blocking analytics scripts — Prevent tracking requests from firing during tests, reducing noise and improving test speed
- Blocking advertisements — Remove ad network requests that introduce non-determinism and slow page loads
- Blocking third-party trackers — Eliminate external dependencies that may be unreliable in CI environments
- Blocking unnecessary resources — Skip loading large assets (images, videos, fonts) when testing functionality that does not depend on them
- Testing failure handling — Verify that the application gracefully handles resource loading failures
Usage
Request blocking is the simplest form of interception. It is used when the test does not need the resource at all and wants to ensure the request never completes. This is the default behavior when intercept() is called with only a URL pattern and no action parameter.
Common use cases include:
- Speeding up test execution by blocking heavy but irrelevant resources
- Ensuring test isolation by preventing external service calls
- Testing application resilience when specific resources fail to load
Theoretical Basis
Request blocking operates through the following mechanism:
intercept(urlPattern) called with no action parameter
│
▼
Interceptor registered with action = undefined
│
▼
Matching request is paused by Fetch.requestPaused
│
▼
handleInterceptor checks action → falsy
│
▼
Fetch.failRequest({ requestId, reason: "Failed" })
│
▼
Browser treats request as a network failure
The "Failed" error reason maps to the Chrome DevTools Protocol Network.ErrorReason enumeration. The browser interprets this as a generic network failure, which triggers standard error handling in the web application (e.g., onerror handlers on script tags, rejected fetch promises, or image loading failures).
Because the failure happens before any network activity, blocked requests have zero network latency, contributing to faster test execution.