Network interception (CDP) in Selenium Java - Deep Dive

Overview - Network interception (CDP)

What is it?

Network interception using CDP (Chrome DevTools Protocol) is a way to watch, modify, or block network requests and responses while running automated browser tests. It lets testers see what data the browser sends and receives, and even change it on the fly. This helps test how web apps behave under different network conditions or with altered data.

Why it matters

Without network interception, testers can only observe the final web page, not the behind-the-scenes data flow. This limits the ability to catch bugs related to network errors, slow responses, or unexpected data. Network interception helps find hidden problems early, making apps more reliable and user-friendly.

Where it fits

Before learning network interception, you should understand basic Selenium WebDriver usage and browser automation. After mastering interception, you can explore advanced testing like performance testing, security testing, and mocking backend services.

Mental Model

Core Idea

Network interception with CDP lets you control and observe browser network traffic during tests to simulate real-world scenarios and catch hidden bugs.

Think of it like...

It's like having a walkie-talkie between you and a delivery driver, where you can listen to what packages are being sent, change the package contents, or stop deliveries before they reach the house.

┌─────────────────────────────┐
│       Test Script           │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│    Selenium WebDriver       │
│  (Controls the browser)     │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Chrome DevTools Protocol     │
│ (Intercepts network traffic)│
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│    Browser & Network         │
│ (Requests & Responses flow) │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Browser Network Traffic

Concept: Learn what network requests and responses are in a browser context.

When you open a website, your browser sends requests to servers asking for files like HTML, images, or data. The server replies with responses containing those files. This back-and-forth is called network traffic.

Result

You understand that every webpage load involves many network requests and responses happening behind the scenes.

Knowing that web pages depend on network traffic helps you see why controlling or watching this traffic is important for testing.

2

Foundation

Basics of Selenium WebDriver Automation

Concept: Learn how Selenium controls browsers to automate user actions.

Selenium WebDriver lets you write code that opens a browser, clicks buttons, fills forms, and reads page content automatically. It simulates what a real user does.

Result

You can write simple tests that open a page and check if elements appear as expected.

Understanding Selenium basics is essential because network interception extends Selenium's control to the browser's network layer.

3

Intermediate

Introduction to Chrome DevTools Protocol (CDP)

🤔Before reading on: do you think Selenium alone can intercept network traffic? Commit to your answer.

Concept: CDP is a special browser interface that allows deep control over Chrome's internals, including network traffic.

Chrome DevTools Protocol lets tools talk directly to the browser to inspect and modify things like network requests, console logs, and performance. Selenium can use CDP commands to intercept network traffic.

Result

You realize Selenium alone can't intercept network traffic, but combined with CDP, it can.

Knowing CDP is the bridge to network interception explains why Selenium tests can now watch and change network data.

4

Intermediate

Setting Up Network Interception in Selenium Java

🤔Before reading on: do you think network interception requires complex setup or just a few lines of code? Commit to your answer.

Concept: Learn how to enable network interception using Selenium's CDP support in Java.

In Selenium Java, you create a DevTools session from your ChromeDriver instance. Then you enable network interception by sending CDP commands to listen to network events like requestWillBeSent and responseReceived.

Result

You can capture network requests and responses during your test runs.

Understanding how to start a DevTools session and subscribe to network events is key to controlling network traffic in tests.

5

Intermediate

Modifying Network Requests and Responses

🤔Before reading on: do you think you can change network data on the fly or only observe it? Commit to your answer.

Concept: Learn how to block, modify, or mock network requests and responses using CDP in Selenium Java.

Using CDP commands like Network.setRequestInterception, you can pause requests and modify headers or body before continuing. Similarly, you can mock responses to simulate server errors or delays.

Result

You can simulate network failures or altered data to test app behavior under different conditions.

Knowing how to change network data helps you test edge cases that are hard to reproduce otherwise.

6

Advanced

Handling Asynchronous Network Events Reliably

🤔Before reading on: do you think network events always arrive in order and instantly? Commit to your answer.

Concept: Learn how to manage timing and concurrency issues when intercepting network traffic in tests.

Network events happen asynchronously and can arrive out of order. You must handle event listeners carefully, use synchronization, and avoid race conditions to ensure your test logic matches the network flow.

Result

Your tests become stable and reliable even when network traffic is complex or slow.

Understanding asynchronous event handling prevents flaky tests and false failures.

7

Expert

Advanced CDP Network Interception Patterns

🤔Before reading on: do you think network interception can fully replace backend mocks? Commit to your answer.

Concept: Explore advanced uses like chaining multiple interceptions, combining with performance metrics, and limitations of CDP interception.

Experts use CDP interception to simulate complex scenarios like slow networks, partial failures, or security attacks. However, CDP interception can't replace full backend mocks for complex logic. Combining CDP with other tools yields best results.

Result

You gain a nuanced understanding of when and how to use network interception effectively in production tests.

Knowing the strengths and limits of CDP interception helps you design robust test suites that balance realism and control.

Under the Hood

CDP works by opening a WebSocket connection between the test code and the browser. This connection allows sending commands and receiving events about browser internals, including network traffic. When network interception is enabled, the browser pauses requests and responses, sending details to the test code, which can then modify or block them before continuing.

Why designed this way?

CDP was designed to give developers deep control over the browser for debugging and automation. It uses a WebSocket protocol for real-time, bidirectional communication. This design allows tools like Selenium to extend beyond UI automation into network and performance testing without changing browser code.

┌───────────────┐       WebSocket       ┌───────────────┐
│ Test Code     │◄─────────────────────►│ Browser (CDP) │
│ (Selenium)    │                       │               │
└──────┬────────┘                       └──────┬────────┘
       │                                        │
       │  Network Commands & Events             │
       │                                        │
       ▼                                        ▼
┌───────────────┐                       ┌───────────────┐
│ Network Layer │◄─────────────────────►│ HTTP Requests │
│ (Intercepts)  │                       │ & Responses   │
└───────────────┘                       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does enabling network interception slow down your tests significantly? Commit to yes or no.

Common Belief: Network interception always makes tests too slow to be practical.

Reality: While interception adds some overhead, careful use and filtering minimize slowdowns, keeping tests efficient.

Why it matters: Believing interception is too slow may prevent testers from using a powerful tool that catches critical bugs.

Quick: Can Selenium intercept network traffic without CDP? Commit to yes or no.

Common Belief: Selenium WebDriver alone can intercept and modify network requests.

Reality: Selenium alone cannot intercept network traffic; it requires CDP or external proxies.

Why it matters: Misunderstanding this leads to wasted effort trying unsupported techniques and missing proper interception methods.

Quick: Does network interception replace the need for backend mocks? Commit to yes or no.

Common Belief: Network interception can fully replace backend service mocks in tests.

Reality: Interception is powerful but limited; complex backend logic often requires dedicated mocks or stubs.

Why it matters: Overreliance on interception can cause incomplete tests and missed backend integration issues.

Quick: Are network events always received in the order requests are sent? Commit to yes or no.

Common Belief: Network events arrive in strict order matching request sequence.

Reality: Network events can arrive out of order due to asynchronous processing and network delays.

Why it matters: Assuming ordered events causes flaky tests and incorrect assertions.

Expert Zone

1

CDP network interception can be combined with browser performance metrics to correlate network delays with UI responsiveness.

2

Intercepted requests can be selectively modified based on URL patterns or headers, allowing fine-grained control in complex apps.

3

Some network features like HTTP/2 multiplexing or WebSocket frames require special handling and are not fully supported by basic interception.

When NOT to use

Avoid network interception when testing complex backend logic that requires stateful mocks or database interactions; use dedicated mock servers or service virtualization instead.

Production Patterns

In real-world tests, teams use CDP interception to simulate slow or failing networks, inject faulty data, and verify app resilience. It is often combined with CI pipelines to catch regressions early.

Connections

API Mocking

Network interception builds on the idea of API mocking by modifying live network traffic instead of replacing backend endpoints.

Understanding API mocking helps grasp how interception can simulate backend behavior dynamically during tests.

Event-Driven Programming

Network interception relies on listening to asynchronous network events and reacting to them in real time.

Knowing event-driven programming clarifies how to handle network events properly and avoid race conditions.

Telecommunications Packet Sniffing

Both network interception and packet sniffing involve capturing and analyzing data packets traveling over a network.

Recognizing this connection shows how software testing borrows concepts from network engineering to improve reliability.

Common Pitfalls

#1 Ignoring asynchronous nature of network events causing flaky tests.

Wrong approach:

driver.getDevTools().addListener(Network.requestWillBeSent(), event -> {
// Immediately assert request details here
});

Correct approach:

Use synchronization or wait mechanisms to ensure network events are fully processed before assertions.

Root cause:

Misunderstanding that network events happen asynchronously and may not be ready when assertions run.

#2 Trying to intercept network without enabling request interception.

Wrong approach:

DevTools devTools = driver.getDevTools();
devTools.createSession();
// No Network.enable or setRequestInterception called
// Trying to listen to requests anyway

Correct approach:

Call Network.enable() and Network.setRequestInterception() before listening to network events.

Root cause:

Not knowing that interception must be explicitly enabled in CDP.

#3 Modifying requests without continuing them, causing browser hang.

Wrong approach:

On intercepted request, modify headers but forget to call continueRequest(), so browser waits forever.

Correct approach:

Always call continueRequest() or failRequest() after modifying to let browser proceed.

Root cause:

Forgetting that intercepted requests must be explicitly continued or aborted.

Key Takeaways

Network interception with CDP extends Selenium's power by letting you watch and change browser network traffic during tests.

It helps simulate real-world network conditions and hidden bugs that normal UI tests miss.

Using CDP requires understanding asynchronous event handling and explicit enabling of interception.

Interception is powerful but not a full replacement for backend mocks or service virtualization.

Mastering network interception improves test reliability, coverage, and insight into app behavior.

Practice

1. What is the main purpose of using Network Interception with Selenium DevTools Protocol (CDP)?

easy

A. To replace Selenium WebDriver with a faster browser engine

B. To speed up test execution by skipping UI rendering

C. To monitor and control network requests and responses during tests

D. To automatically generate test data from network traffic

Solution

1. Step 1: Understand Network Interception

   Network interception allows tests to watch and manipulate network traffic between the browser and server.

2. Step 2: Identify the purpose in Selenium CDP context

   Selenium's DevTools Protocol integration enables listening to and controlling network events during tests.

3. Final Answer:

   To monitor and control network requests and responses during tests -> Option C

4. Quick Check:

   Network interception = monitor and control traffic [OK]

Hint: Network interception means watching and controlling web traffic [OK]

Common Mistakes:

• Thinking it speeds up tests by skipping UI
• Confusing it with test data generation
• Assuming it replaces WebDriver

2. Which Java code snippet correctly creates a DevTools session to enable network interception in Selenium 4+?

easy

A. DevTools devTools = driver.getDevTools(); devTools.startSession(); Network.enable();

B. DevTools devTools = new DevTools(); devTools.startSession(); devTools.enableNetwork();

C. DevTools devTools = driver.createDevTools(); devTools.start(); Network.enable();

D. DevTools devTools = driver.getDevTools(); devTools.createSession(); devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty()));

Solution

1. Step 1: Check correct DevTools session creation

   In Selenium 4+, use driver.getDevTools() and then createSession() to start.

2. Step 2: Verify enabling network interception

   Use devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty())) to enable network events.

3. Final Answer:

   DevTools devTools = driver.getDevTools(); devTools.createSession(); devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty())); -> Option D

4. Quick Check:

   Use getDevTools(), createSession(), then send Network.enable [OK]

Hint: Use driver.getDevTools() then createSession() before enabling network [OK]

Common Mistakes:

• Trying to instantiate DevTools with new keyword
• Calling Network.enable() without devTools.send()
• Missing createSession() call

3. Given the following code snippet, what will be printed when a network request is intercepted?

DevTools devTools = driver.getDevTools();
devTools.createSession();
devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty()));
devTools.addListener(Network.requestWillBeSent(), request -> {
    System.out.println("Request URL: " + request.getRequest().getUrl());
});
// Browser navigates to https://example.com

medium

A. Request URL: https://example.com/

B. Request URL: null

C. No output because listener is not added correctly

D. Compilation error due to missing imports

Solution

1. Step 1: Understand listener setup

   The listener is added to Network.requestWillBeSent event, printing the URL of each request.

2. Step 2: Predict output on navigating to example.com

   When browser navigates, a request is sent to https://example.com/, triggering the listener and printing the URL.

3. Final Answer:

   Request URL: https://example.com/ -> Option A

4. Quick Check:

   Listener prints request URL on navigation [OK]

Hint: Listener prints URL of each request sent during navigation [OK]

Common Mistakes:

• Assuming listener won't trigger without explicit start
• Expecting null URL in request
• Thinking listener setup is incorrect

4. Identify the error in this Selenium Java code snippet for blocking image requests using CDP:

DevTools devTools = driver.getDevTools();
devTools.createSession();
devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty()));
devTools.addListener(Network.requestWillBeSent(), request -> {
    if(request.getRequest().getUrl().endsWith(".png")) {
        devTools.send(Network.setBlockedURLs(List.of(request.getRequest().getUrl())));
    }
});

medium

A. Calling setBlockedURLs inside the listener causes repeated blocking calls

B. Missing call to devTools.createSession() before enabling network

C. Using endsWith(".png") is invalid for URL filtering

D. Network.enable() should not be called with Optional.empty()

Solution

1. Step 1: Analyze listener behavior

   The listener calls setBlockedURLs every time a request ends with .png, causing repeated calls.

2. Step 2: Understand correct usage of setBlockedURLs

   setBlockedURLs should be called once with all URLs to block, not repeatedly inside the listener.

3. Final Answer:

   Calling setBlockedURLs inside the listener causes repeated blocking calls -> Option A

4. Quick Check:

   setBlockedURLs called repeatedly inside listener is wrong [OK]

Hint: Call setBlockedURLs once, not inside each request event [OK]

Common Mistakes:

• Calling setBlockedURLs repeatedly inside listener
• Forgetting to create session before enabling network
• Misusing string methods for URL filtering

5. You want to modify the response body of a JSON API call during a Selenium test using CDP. Which approach correctly achieves this?

hard

A. Use Network.requestWillBeSent to change the request URL to a local JSON file

B. Enable Network.requestIntercepted event, fetch response body, modify it, then use Network.continueInterceptedRequest with modified body

C. Call Network.setBlockedURLs to block the API call and serve a local file instead

D. Modify the DOM after page load to replace JSON data

Solution

1. Step 1: Understand response modification with CDP

   To modify a response, intercept it, get the body, change it, and continue with the new content.

2. Step 2: Identify correct event and method usage

   Use Network.requestIntercepted to detect response, fetch body, then Network.continueInterceptedRequest to send modified response.

3. Final Answer:

   Enable Network.requestIntercepted event, fetch response body, modify it, then use Network.continueInterceptedRequest with modified body -> Option B

4. Quick Check:

   Modify response by intercepting and continuing with new body [OK]

Hint: Intercept response, modify body, then continue intercepted request [OK]

Common Mistakes:

• Trying to modify request instead of response
• Blocking URL instead of modifying response
• Changing DOM instead of network response