In the world of web automation testing, Quality Assurance (QA) professionals often encounter flaky tests caused by slow network responses, unstable third-party APIs, or dynamic data. Wouldn’t it be great if QA could “control” what the API returns or even block unnecessary calls (like ads)? That’s exactly where Playwright’s network interception and mocking feature shines.

Playwright is a modern automation framework that supports multiple languages (C#, Java, JavaScript, Python). It gives us powerful tools to:

• Intercept network requests & responses
• Mock API data
• Simulate errors
• Control third-party dependencies

In this blog, we’ll walk through everything – from setup to real-world usage – using Playwright with C#.

If you’re new to API testing in Playwright or need help setting up your project, check out this blog: Enhancing API Automation Testing with Playwright and TypeScript: GET and POST Operations Explained.

Importance of Intercepting or Mocking Network Calls in Test Automation

Intercepting and mocking network calls offer several benefits in test automation:

1. Isolate Frontend Testing: Test the frontend independently by mocking API responses without relying on the backend.
2. Handle Third-Party Dependencies: Simulate third-party APIs to avoid dependency on external systems.
3. Speed Up Tests: Reduce test execution time by bypassing real network delays.
4. Simulate Edge Cases: Test scenarios like server errors (500), unauthorized access (401), or empty responses that may be hard to reproduce with a real backend.
5. Ensure Data Consistency: Provide predictable and consistent responses to avoid flakiness in tests caused by dynamic data.

Understanding Network Interception and Mocking

What is Network Interception?

Network interception allows you to observe or manipulate HTTP requests and responses while running a test. For example, you can:

• Log every API call our app makes
• Block some requests (e.g., ads or analytics)
• Modify requests on the fly

What is Mocking?

Mocking replaces the actual API response with fake (mocked) data. This is useful when:

• The backend is not ready
• You want to simulate errors or slow responses
• You want predictable data in your tests

Difference Between Interception & Mocking

Benefits of Mocking in Tests

• Faster execution (no waiting for real APIs)
• Better stability (no flaky responses)
• Ability to test rare scenarios (like 500 errors)

How to Set Up Playwright with C#

• Step 1: Create a .NET Console Project
  • dotnet new console -n PlaywrightNetworkDemo
  • cd PlaywrightNetworkDemo
• Step 2: Add Playwright
  • dotnet add package Microsoft.Playwright
  • playwright install
• Step 3: Program.cs Structure
  • Your Program.cs will contain all the code for the examples. Here’s a base structure:

using Microsoft.Playwright;
using System.Text.Json;

class Program
{
    public static async Task Main()
    {
        using var playwright = await Playwright.CreateAsync();

        var browser = await playwright.Chromium.LaunchAsync(new BrowserTypeLaunchOptions 
        { 
            Headless = false 
        });

        var context = await browser.NewContextAsync();
        var page = await context.NewPageAsync();

        // Your code examples will go here
    }
}

Capturing & Logging Network Requests and Responses

Steps:
Step 1: Create a Simple HTML Page that Triggers an API Call

Step 2: Save this file locally
Example path:
C:\Users\XXXX\OneDrive\Documents\CapturingAndLoggingNetworkRequestAndResponse.html

Step 3: Create a Playwright Test Project with C#

Use Visual Studio and install the required NuGet packages:

• ‘Microsoft.Playwright’
• ‘NUnit’
• ‘Microsoft.NET.Test.Sdk’
• ‘NUnit3TestAdapter’

Step 4: Write a Playwright test to open the HTML file

Use Visual Studio and install the required NuGet packages:

• ‘Microsoft.Playwright’
• ‘NUnit’
• ‘Microsoft.NET.Test.Sdk’
• ‘NUnit3TestAdapter’

Step 5: Capture and log outgoing requests

Step 6: Capture and log responses + add assertions

Step 7: Click the button on the page to trigger the API call

Step 8: Add a wait so the response is captured properly

Complete Class file

Output:

Blocking Specific Requests (e.g., ads, tracking)

What Is “Blocking Specific Requests”?

In Playwright, user can intercept network requests and decide whether to:

• Allow them,
• Modify them, or
• Block them completely.

Where and Why Do We Use This?

Scenario: Why We Block Requests

Example: The user wants to verify that a “User Not Found” error is displayed correctly when the API fails. Instead of disabling the server, the user just blocks the request.

Steps:

Step 1: Create a simple HTML page that triggers an API call
Create a file CapturingAndLoggingNetworkRequestAndResponse.html with the following content:

Step 2: Playwright Test to Block the API request

Step 3: Log the Requests and Responses (Optional but Helpful)
This helps debug what’s happening:

Step 4: Open the HTML Page in the Browser

Step 5: Trigger the Network Request from the Page
Click the button that makes the fetch call:

Step 6: Wait and Assert if Block Happened

Real-World Use Example

Imagine testing a “Get User Details” feature, and the API is sometimes down. You want to check:
Does your UI show “User not found” properly?

• Does the error message appear?
• Do fallback mechanisms work?

Using Playwright’s blocking:

• You simulate an API failure.
• You test your app’s resilience.
• Without needing actual server downtime.

Block requests to external domains like Google Fonts, Ads, etc.

• An HTML page that loads some fonts or ads from external sources, like:
  Google Fonts (fonts.googleapis.com, fonts.gstatic.com)
• Analytics or Ads (like doubleclick.net, googletagmanager.com)

In test environments, we often want to:

• Block these to speed up testing
• Avoid network noise or tracking
• Simulate network failures

Steps to Blocking External Domains

Step 1: Create an HTML File. Name is:
BlockExternalRequestsExample.html

Step 2: Playwright Test.- Test Class name is: BlockMultipleExternalRequests.cs

[Test]
public async Task BlockMultipleExternalRequests()
{
using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });

var context = await browser.NewContextAsync();
var page = await context.NewPageAsync();

// Flags to detect whether any blocked resource was responded to
bool gotGoogleFontResponse = false;
bool gotGoogleAdsResponse = false;
bool gotJqueryCDNResponse = false;

// Block Google Fonts
await context.RouteAsync("**/fonts.googleapis.com/**", async route =>
{
    Console.WriteLine("Blocking Google Fonts: " + route.Request.Url);
    await route.AbortAsync();
});

// Block Google Ads
await context.RouteAsync("**/pagead2.googlesyndication.com/**", async route =>
{
    Console.WriteLine("Blocking Google Ads: " + route.Request.Url);
    await route.AbortAsync();
});

// Block jQuery CDN
await context.RouteAsync("**/code.jquery.com/**", async route =>
{
    Console.WriteLine("Blocking jQuery CDN: " + route.Request.Url);
    await route.AbortAsync();
});

// Log responses (to detect if any blocked requests still responded)
page.Response += async (_, response) =>
{
    if (response.Url.Contains("fonts.googleapis.com"))
        gotGoogleFontResponse = true;

    if (response.Url.Contains("pagead2.googlesyndication.com"))
        gotGoogleAdsResponse = true;

    if (response.Url.Contains("code.jquery.com"))
        gotJqueryCDNResponse = true;

    Console.WriteLine($"Received: {response.Status} - {response.Url}");
};

// Load your local HTML file
string localPath = "C:\\Users\\XXXX\\OneDrive\\Documents\\BlockExternalRequestsExample.html";
await page.GotoAsync(localPath);
await page.WaitForTimeoutAsync(3000); // Wait for all requests

// Assertions – none of these should have responded
Assert.That(gotGoogleFontResponse, Is.False, "Google Fonts request was not blocked.");
Assert.That(gotGoogleAdsResponse, Is.False, "Google Ads request was not blocked.");
Assert.That(gotJqueryCDNResponse, Is.False, "jQuery CDN request was not blocked.");

}

Output:

Real World Benefit:

• No need to load fonts/ads during test
• Tests become faster and more reliable
• Simulate CDN failure, third-party unavailability

Redirecting Requests to a Different Endpoint

Use:
Suppose your HTML calls this API:
https://jsonplaceholder.typicode.com/users/2
But you want to redirect it to:
https://jsonplaceholder.typicode.com/users/1

Steps:

Step 1: HTML File- Save this as RedirectRequestDemo.html

Step 2: Playwright C# Test Code – Redirecting Request

[Test]
public async Task RedirectUserRequestToAnotherEndpoint()
{
using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
var context = await browser.NewContextAsync();
var page = await context.NewPageAsync();

// Flag to check if redirect happened
bool redirected = false;

// Intercept and redirect request
await context.RouteAsync("**/users/2", async route =>
{
    var originalUrl = route.Request.Url;
    var redirectedUrl = "https://jsonplaceholder.typicode.com/users/1";

    Console.WriteLine($"Redirecting: {originalUrl}  {redirectedUrl}");
    redirected = true;

    var headers = new Dictionary<string, string>(route.Request.Headers);

    await route.ContinueAsync(new RouteContinueOptions
    {
        Url = redirectedUrl,
        Method = route.Request.Method,
        Headers = headers
    });
});

// Log response
page.Response += async (_, response) =>
{
    if (response.Url.Contains("/users/1"))
    {
        Console.WriteLine($"Final Response from redirected URL: {response.Url}");
        var body = await response.TextAsync();
        Console.WriteLine($"Body: {body}");
    }
};

// Load the HTML page
string localPath = "C:\\Users\\harsh\\OneDrive\\Documents\\RedirectRequestDemo.html";
await page.GotoAsync(localPath);
await page.ClickAsync("text=Fetch User Data");

await page.WaitForTimeoutAsync(3000); // Wait for API to resolve

// Assert
Assert.That(redirected, Is.True, "The request was not redirected.");

}

Output:

Real-World Use Cases: Redirecting Requests

Mocking Network Responses with Playwright

Why Do We Mock Network Responses in Automation Testing?

Steps:

The API endpoint, which we will mock, is:
https://jsonplaceholder.typicode.com/users/2
And, instead of an actual response, we will inject:

{
"id": 2,
"name": "Mocked User",
"email": "mock@demo.com"
}

Step 1: Create a Simple HTML File (e.g., mockDemo.html)
Save this in system (e.g., in Documents):

Step 2: Create a Test Class – VerifyMockedUserDataAppearsInUI

[Test]
public async Task VerifyMockedUserDataAppearsInUI()
{
using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
var context = await browser.NewContextAsync();
var page = await context.NewPageAsync();

// Step 1: Intercept and mock the API response
await context.RouteAsync("**/users/2", async route =>
{
    var mockedUser = new
    {
        id = 2,
        name = "Mocked User",
        email = "mock@demo.com"
    };

    string mockedJson = JsonSerializer.Serialize(mockedUser);

    await route.FulfillAsync(new RouteFulfillOptions
    {
        Status = 200,
        ContentType = "application/json",
        Body = mockedJson
    });

    Console.WriteLine("Sent mocked response.");
});

// Step 2: Load the local HTML file
string localFilePath = "C:\\Users\\XXXX\\OneDrive\\Documents\\MockUserPage.html";
await page.GotoAsync("file://" + localFilePath);
await page.WaitForLoadStateAsync(LoadState.DOMContentLoaded);

// Step 3: Trigger the fetch
await page.ClickAsync("text=Fetch User Data");

// Step 4: Wait for the result to appear and verify it
var result = page.Locator("#result");
await Assertions.Expect(result).ToHaveTextAsync("Mocked User: Mocked User");

Console.WriteLine("Assertion passed. UI shows mocked response.");

}

Output UI:

Dynamic Mock Data

We can also use Faker or static methods to generate runtime mock data.
var randomId = new Random().Next(1000, 9999);
var mockData = new { id = randomId, message = “Hello from mock!” };

Advanced Mocking Techniques

a. Simulating 500 Internal Server Error

This is useful when you want to test how your frontend handles server failures like internal errors, service crashes, etc.

Steps:

Step 1: Create an HTML file in the documents folder. – ErrorHandlingTest.html

Step 2: C# Playwright Test – Simulate 500 Error

[Test]
public async Task ShouldDisplayErrorMessageOn500Error()
{
using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
var context = await browser.NewContextAsync();
var page = await context.NewPageAsync();

// Mock 500 Internal Server Error for /users/2
await context.RouteAsync("**/users/2", async route =>
{
    await route.FulfillAsync(new RouteFulfillOptions
    {
        Status = 500,
        ContentType = "application/json",
        Body = "{\"error\": \"Internal Server Error\"}"
    });
    Console.WriteLine("Simulated 500 response for /users/2");
});

// Load local HTML file
string filePath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "ErrorHandlingTest.html");
await page.GotoAsync("file://" + filePath);
await page.WaitForLoadStateAsync(LoadState.DOMContentLoaded);

// Trigger fetch
await page.ClickAsync("text=Fetch User Data");

// Assert error message is displayed
var resultLocator = page.Locator("#result");
await Assertions.Expect(resultLocator).ToHaveTextAsync("Failed to load data");

await page.WaitForTimeoutAsync(3000); // Optional visual pause for demo
Console.WriteLine("Assertion passed: UI displayed fallback message.");

}

Notes:
This does not hit the real server; it intercepts and mocks a 500 response. We can simulate other statuses like 403, 404, 503, the same way. Always test our frontend UI behavior under failure conditions for reliability.

Output in Visual Studio:

Output in UI:

b. Simulating Timeout (No Response)

This test helps us test how our frontend behaves when a request hangs and never completes.

Real-World Use Cases of Simulating Timeouts

Steps:
Step 1: Create an HTML file – TimeoutSimulation.html

Step 2: Playwright + C# Test: Simulate Timeout

[Test]
public async Task ShouldHandleTimeoutGracefully()
{
using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
var context = await browser.NewContextAsync();
var page = await context.NewPageAsync();

// Simulate hanging request (timeout)
await context.RouteAsync("**/users/2", async route =>
{
    Console.WriteLine("Simulating no response...");
    await Task.Delay(10000); // Hang for 10 seconds
});

string localPath = "C:\\Users\\harsh\\OneDrive\\Documents\\TimeoutSimulation.html";
await page.GotoAsync("file://" + localPath);
await page.WaitForLoadStateAsync(LoadState.DOMContentLoaded);

await page.ClickAsync("text=Fetch User");

// Wait for frontend timeout and UI update
await page.WaitForTimeoutAsync(6000);

// Assertion
var resultLocator = page.Locator("#result");
await Assertions.Expect(resultLocator).ToHaveTextAsync("Request Timed Out");

Console.WriteLine("Timeout was correctly handled in the UI.");

}

Output in UI:

Output in VS:

c. Mocking Third-Party APIs (e.g., payment gateways)

Mocking third-party APIs like payment gateways (e.g., Stripe, Razorpay, PayPal) is essential for testing without hitting the real service, incurring costs, or dealing with delays or side effects (e.g., sending money).

Steps:
Step 1: HTML (PaymentPage.html)

Step 2: C# Test Code – Mocking the Payment API

[Test]
public async Task ShouldMockPaymentGatewaySuccessfully()
{
using var playwright = await Playwright.CreateAsync();
await using var browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
var context = await browser.NewContextAsync();
var page = await context.NewPageAsync();

// Mock the third-party payment gateway API
await context.RouteAsync("**/api/pay", async route =>
{
    var mockPaymentResponse = new
    {
        transactionId = "txn_mock_12345",
        status = "Success",
        amount = 500
    };

    var mockJson = JsonSerializer.Serialize(mockPaymentResponse);

    await route.FulfillAsync(new RouteFulfillOptions
    {
        Status = 200,
        ContentType = "application/json",
        Body = mockJson
    });

    Console.WriteLine("Mocked Payment API response sent.");
});

// Load the local HTML file
string localFile = "C:\\Users\\XXXX\\OneDrive\\Documents\\PaymentPage.html";
await page.GotoAsync(localFile);
await page.WaitForLoadStateAsync(LoadState.DOMContentLoaded);

// Click to initiate mocked payment
await page.ClickAsync("text=Pay ₹500");

// Assert result is displayed correctly
var result = page.Locator("#result");
await Assertions.Expect(result).ToHaveTextAsync("Payment Status: Success");
await page.WaitForTimeoutAsync(3000);

Console.WriteLine("Assertion passed: Mocked payment response verified.");

}

Output in UI:

Combining Mocking with Other Playwright Features

You can combine mocking with:
Use mocking in fixtures for consistent test setups. Combine with screenshot and tracing toolsIntegrate with BrowserContext for parallel scenarios.
Example:
await page.ScreenshotAsync(new PageScreenshotOptions { Path = “mockedpage.png” });

CI/CD Integration Tips

Benefits of CI/CD

• Tests run even if the backend is down
• You can simulate slow or error conditions easily
• Your pipelines are faster and more stable

Best Practices

• Separate mock logic from core test logic -Use environment flags (isMock=true) to control mocking -Log actual vs mocked endpoints

Common Challenges and How to Handle

Real-World Use Cases

Case 1: Mocked payment API to test success/failure flow
Case 2: Replaced slow user profile API to speed up login tests
Case 3: Simulated GraphQL API when the backend was under maintenance

Prerequisite

Place this at the top of your file:

using Microsoft.Playwright;
using NUnit.Framework;
using System.Text.Json;

Here is the test class and test setup:

[TestFixture]
public class MockedApiTests
{
private IBrowser _browser;
private IBrowserContext _context;
private IPage _page;

[SetUp]
public async Task Setup()
{
    var playwright = await Playwright.CreateAsync();
    _browser = await playwright.Chromium.LaunchAsync(new() { Headless = false });
    _context = await _browser.NewContextAsync();
    _page = await _context.NewPageAsync();
}

[TearDown]
public async Task TearDown()
{
    await _context.CloseAsync();
    await _browser.CloseAsync();
}

}

Case 1: Mocked Payment API – Success Flow

We can’t hit the real payment gateway repeatedly, so we’ll use a mock one.
We’re testing a payment feature on a webpage,

but instead of calling the real backend API, we will:

• Mock a fake successful response
• Intercept the payment request

Verify that the UI updates correctly with “Payment Successful!”

This is useful when: The real payment API is not ready You don’t want to make real transactions you want to test both success and failure flows

Step 1: HTML File

What it does:
It has a button, ‘Make Payment’

Step 2: Test with Playwright:

When clicked, it calls https://api.example.com/payment
Based on the response status (success or failure), it shows a message

Step 3: Test with Playwright:

Case 2: Replaced slow user profile API to speed up login tests

Scenario:
We have a login flow where the app fetches user profile details from /user/profile after clicking a login button.
But: The actual API is slow and takes time to respond. We want to speed up the test by intercepting and mocking the API.

GOAL:

• Intercept the ‘/user/profile’ request.
• Respond instantly with fake data ({“name”: “QA Tester”}).
• Assert that the frontend shows: “Welcome, QA Tester”

Steps:
Step 1: Create an HTML file called profile.html

Step 2: Playwright Test – UserProfileApi_ShouldBeMockedQuickly

• RouteAsync(“**/user/profile” – intercepts any request matching ‘/user/profile’
• FulfillAsync(…) – Responds immediately with { “name”: “QA Tester” }
• GotoAsync(…) – Loads the local HTML page
• ClickAsync(…) – Simulates user clicking “Login”
• TextContentAsync(“#welcome”) – Captures the welcome message
• Assert.AreEqual(…) – Confirms the UI shows the expected result

Output in UI:

Case 3: Simulated GraphQL API when the backend was under maintenance

Scenario

We are working with a frontend that sends a GraphQL query to https://api.example.com/graphql to fetch user info. But sometimes, The backend is under maintenance. We still want to test the UI flow So, we mock the GraphQL response

Goal

• Intercept POST request to /graphql
• Identify the query: { getUserInfo { id name } }
• Mock the response: { id: “123”, name: “QA Automation Tester” }
• Verify UI shows: ID: 123, Name: QA Automation Tester

Steps:

Step 1: Create an HTML file- graphql.html

Step 2: Create playwright test – MockedGraphQLApi_ShouldReturnStaticUserInfo

Output:

Why GraphQL Mocking is Powerful

• Backend can be down or slow, you can still test the UI
• GraphQL has nested and structured responses easily faked
• Useful when you’re working on frontend-first development
• Ensures CI/CD pipelines don’t break due to backend outages

Best Practices for Network Interception and Mocking

• Use Specific Patterns: Avoid intercepting all requests unless necessary. Use specific URL patterns to match the target API.
• Clean-Up Routes: Ensure that routes are cleared after the test to avoid interference with other tests.
• Combine with Assertions: Always validate that the front end behaves as expected after intercepting or mocking.
• Simulate Realistic Scenarios: Mock responses that closely resemble real-world scenarios to ensure accurate test coverage.
• Log and Debug: Log network calls during development to understand application behavior and refine your mocks.

Conclusion

Network interception and mocking have become critical components of modern QA automation strategies.
Playwright, particularly with C#, streamlines their implementation, contributing to faster, more stable, and
reliable test suites. Emerging trends, such as AI-powered mock servers, visual mock editors, and tools
that convert live traffic into reusable mocks, are poised to redefine automation workflows.
Incorporating these practices ensures significant time savings and improved efficiency in debugging and
test execution across scalable automation frameworks.

Witness how our meticulous approach and cutting-edge solutions elevated quality and performance to new heights. Begin your journey into the world of software testing excellence. To know more refer to Tools & Technologies & QA Services.

If you would like to learn more about the awesome services we provide,  be sure to reach out.

Happy Testing 🙂