Skip to main content

Quality Assurance

Intercepting and Mocking Network Responses with Selenium Chrome DevTools

Coworkers Team At Work. Group Of Young Business People In Trendy Casual Wear Working Together In Creative Office

In the dynamic landscape of Selenium Chrome DevTools integration, we’ve explored simulating mobile browsing and harnessing real-time insights from network responses using Selenium CDP Listeners. Building upon this foundation, our journey now ventures into the realm of intercepting and mocking network/API responses—a crucial skill for comprehensive web testing. In this article, we’ll embark on a step-by-step guide, showcasing how Selenium, coupled with Chrome DevTools, empowers testers to intercept and manipulate network/API responses.

To learn more about Selenium and CDP, you can refer to my previous blogs

Optimizing Web Testing: Mastering Mobile Simulation with Selenium CDP Device Metrics Override / Blogs / Perficient

Decoding Web Interactions: Unleashing Selenium CDP Listeners to Extract Network Responses / Blogs / Perficient

Interception and Modification of Network Request

We can intercept the network request by pausing the request, making changes in the request, and then continuing the request with the changes made.

Let us understand it with a simple scenario.

We have a website,, with a “Virtual Library” link that navigates to the Library page displaying the book list. When there is only one book in the account, it displays the message “Oops, only 1 book is available”, which is associated with the request URL: ““.

But when we navigate to the library page by clicking the “Virtual Library”, the request URL is default set with an account having multiple books: ““.

Hence, to test the message, we cannot directly rely on UI Automation. We have to make changes in the network request URL while sending the request, which is mocking network requests.

This is where the Interception and Mocking of the network request feature come into play.

Step-by-step flow for Mocking Request

Below is the code for the above problem:

public class NetworkMocking {

        public static void main(String[] args) throws InterruptedException {
//Initialize driver  
          System.setProperty("", "/Users/rahulshetty/Documents/chromedriver");
            ChromeDriver driver = new ChromeDriver();
//Create DevTools Object and start session
            DevTools devTools = driver.getDevTools();
//Enable Fetch Domain to work with network requests
            devTools.send(Fetch.enable(Optional.empty(), Optional.empty()));

//Add Listener to pause request
            devTools.addListener(Fetch.requestPaused(), request->
//Filter url with if condition and make changes in URL with replace method
//Mock URL - make change in the url by using replace method and change the authorName
                    String mockedUrl =request.getRequest().getUrl().replace("=shetty", "=BadGuy");
//Continue request with new mock URL                   
                    devTools.send(Fetch.continueRequest(request.getRequestId(), Optional.of(mockedUrl), Optional.of(request.getRequest().getMethod()),
                            Optional.empty(), Optional.empty(),Optional.empty()));
                else {
                    devTools.send(Fetch.continueRequest(request.getRequestId(), Optional.of(request.getRequest().getUrl()), Optional.of(request.getRequest().getMethod()),
                            Optional.empty(), Optional.empty(),Optional.empty()));
//Perform test and verify the message


Below are the functions we have used above:

  1. Fetch.enable:  Enable the Fetch domain, allowing the interception and modification of network requests. It accepts 3 parameters: maxTotalBufferSize(integer), maxResourceBufferSize(integer), and maxPostDataSize(integer), respectively.
  2. Fetch.requestPaused: The requestPaused event triggers when we pause network requests. In this case, it’s paused by the listener to inspect and potentially modify the request.
  3. Fetch.continueRequest: This method continues the paused request with optional modifications. In this case, it continues the request with either the original or modified URL based on the condition.

Hence by following the above process to create a mock network request, we can test the functionality that was otherwise impossible by direct automation.

You can refer to official documentation for more details on various methods and events: Chrome DevTools Protocol


In conclusion, mastering the art of intercepting and mocking network/API responses with Selenium and Chrome DevTools unveils a powerful dimension of web testing. The step-by-step guide empowers testers to dynamically manipulate network requests, enabling comprehensive testing scenarios beyond UI automation. Transitioning from simulating mobile browsing to real-time insights and now intercepting and mocking, Selenium’s capabilities continue to evolve. Stay tuned for more insights into our ongoing exploration. Happy testing!

Thoughts on “Intercepting and Mocking Network Responses with Selenium Chrome DevTools”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Himanshu Pawar

Himanshu Pawar works in Quality assurance at Perficient, based out of India. He is currently working on Adobe technologies. Himanshu is a technology enthusiast passionate about automation and automation tools. He constantly seeks opportunities to learn and explore new technologies.

More from this Author

Follow Us