Intercept & Mock API Requests in Playwright C# | Web Testing Examples

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.

1. 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.
Playwrightis a modern automation framework that supports
Bltiple languages (C#, Java, JavaScript, Python). It gives us
powerful tools to:
Intercept network requests & responses
Mock API data
Intercept & Mock API Requests in
Playwright C# Real Examples for Web
Testers

2. SiBlate 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.
Table Of Content
Importance of Intercepting or Mocking Network Calls in
Test Automation
Understanding Network Interception and Mocking
What is Network Interception?
What is Mocking?
Difference Between Interception & Mocking
Benefqts of Mocking in Tests
How to Set Up Playwright with C#
Capturing & Logging Network Requests and Responses
Blocking Specifqc Requests (e.g., ads, tracking)
What Is “Blocking Specifqc Requests”?
Where and Why Do We Use This?
Real-World Use Example
Block requests to external domains like Google Fonts,
Ads, etc.
Real World Benefqt:
Redirecting Requests to a Different Endpoint
Real-World Use Cases: Redirecting Requests
Mocking Network Responses with Playwright
Why Do We Mock Network Responses in Automation
Testing?

3. Dynamic Mock Data
Advanced Mocking Techniques
a. SiBlating 500 Internal Server Error
b. SiBlating Timeout (No Response)
Real-World Use Cases of SiBlating Timeouts
c. Mocking Third-Party APIs (e.g., payment gateways)
Combining Mocking with Other Playwright Features
CI/CD Integration Tips
Best Practices
Comon Challenges and How to Handle
Real-World Use Cases
Case 1: Mocked Payment API – Success Flow
Case 2: Replaced slow user profqle API to speed up login
tests
Case 3: SiBlated GraphQL API when the backend was
under maintenance
Why GraphQL Mocking is Powerful
Best Practices for Network Interception and Mocking
Conclusion
Importance of Intercepting or Mocking
Network Calls in Test Automation
Intercepting and mocking network calls offer several benefqts in test
automation:
U. Isolate Frontend Testing: Test the frontend independently by
mocking API responses without relying on the backend.
2. Handle Third-Party Dependencies: SiBlate 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),

4. 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 siBlate errors or slow responses
You want predictable data in your tests
Difference Between Interception &
Mocking
Feature Interception Mocking
Observe Traffqc ✅ ✅
Modify/Block ✅ ✅

5. Feature Interception Mocking
Fake responses ❌ ✅
Benefqts 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
});

6. 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

7. Step 2: Save this fqle locally
Example path:
C:\Users\XXXX\OneDrive\Documents\CapturingAndLoggingNetworkRequestA
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 fqle

8. 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

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

10. Step 8: Add a wait so the response is captured properly
Complete Class fqle

11. Output:

12. Blocking Specifqc Requests (e.g., ads,
tracking)
What Is “Blocking Specifqc Requests”?
In Playwright, user can intercept network requests and decide

13. whether to:
Allow them,
Modify them, or
Block them completely.
Where and Why Do We Use This?
Scenario: Why We Block Requests
Reason Description
Third-party ads or trackers
To speed up test execution and avoid
flaky behavior.
Simulating offline errors
To test how the app behaves when
certain APIs fail.
Isolating features
To ensure that only specifqc APIs run
and others don’t interfere.
Cleaner test logs
Avoid unnecessary requests, such as
fonts and analytics.
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 fqle
CapturingAndLoggingNetworkRequestAndResponse.html with the
following content:

14. Step 2: Playwright Test to Block the API request

15. 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

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

17. Step 6: Wait and Assert if Block Happened
Real-World Use Example
Imagine testing a “Get User Details” feature, and the API is sometimes

18. 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 siBlate 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
SiBlate network failures
Steps to Blocking External Domains
Step 1: Create an HTML File. Name is:
BlockExternalRequestsExample.html

19. 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
=>

20. {
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\\BlockExternalRequestsExampl
e.html";
await page.GotoAsync(localPath);

21. 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:

22. Real World Benefqt:
No need to load fonts/ads during test
Tests become faster and more reliable
SiBlate 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

23. 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
});
});

24. // 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:

25. Real-World Use Cases: Redirecting
Requests
Scenario Why Redirect Requests
Mocking live API
Replace real endpoints with mock data
in staging or testing environments
Bypassing failures
If the original API is down or slow,
redirect to a backup or fallback
endpoint
Localization
Redirect real API calls to modifqed or
altered endpoints to test different
responses
Mask sensitive data
Redirect endpoints that return PII to
safe mock APIs during demo or public
access
Local development
Redirect production API to local mock
server to avoid network calls during
dev
Avoid rate limits
Redirect frequently used public APIs to
local or cached copies to prevent
throttling
A/B testing setup
Redirect some API calls to alternate
test endpoints to simulate different

26. Scenario Why Redirect Requests
user flows
Testing variations
Redirect real API calls to modifqed or
altered endpoints to test different
responses
Mocking Network Responses with
Playwright
Why Do We Mock Network Responses in
Automation Testing?
Reason Explanation
Avoid real server dependency
If the real API is down, slow, or under
development, mocking allows you to
test the UI independently.
Faster, more stable tests
Mocked responses return instantly no
network delays, no timeouts, no
flakiness.
Test edge cases easily
The user can simulate rare cases like
500 errors, empty data, or specifqc
payloads without real server help.
Bypass rate limits / auth
Users can mock third-party APIs (e.g.,
Google, Stripe) and avoid hitting actual
limits or login flows.
Simulate data variations
Want to test how UI behaves for a user
with no email? Or a user with 10K
orders? Just mock it.
Protect sensitive data
If the API returns private or real
customer data, mocking replaces it
with safe dummy data.
The user can run tests without internet

27. Reason Explanation
Offline/local testing or backend environments only frontend
+ mocks required.
Controlled, repeatable tests
Users always know what response will
come no randomness, no surprises.
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": "[email protected]"
}
Step 1: Create a Simple HTML File (e.g., mockDemo.html)
Save this in system (e.g., in Documents):

28. 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 = "[email protected]"
};
string mockedJson = JsonSerializer.Serialize(mockedUser);
await route.FulfillAsync(new RouteFulfillOptions
{
Status = 200,
ContentType = "application/json",
Body = mockedJson
});
Console.WriteLine("Sent mocked response.");
});

29. // 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:

30. 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.
Scenario Why simulate a 500 error
Backend is down
See if the frontend shows a user-
friendly message or a retry option
Validate error-handling code
Ensure the app doesn’t crash or
misbehave
Testing fallback logic Trigger fallback UI or alternative flows
Negative testing in CI
Confqrm alert/logging/reporting
systems work correctly
Steps:
Step 1: Create an HTML fqle in the documents folder. –
ErrorHandlingTest.html

31. 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
{

32. 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.M
yDocuments), "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 siBlate other statuses like 403, 404, 503, the
same way. Always test our frontend UI behavior under failure
conditions for reliability.
Output in Visual Studio:

33. Output in UI:

34. 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
Scenario Why simulate it
Slow backend Test loader/spinner or retry logic
No response from the server
Validate the timeout error message and
error handling in the UI
Frontend stability under load
Confqrm the app doesn’t freeze or
behave unexpectedly
Steps:
Step 1: Create an HTML fqle – TimeoutSimulation.html

35. 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

36. 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:

37. 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)

38. 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);

39. 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:

40. Combining Mocking with Other
Playwright Features
You can combine mocking with:
Use mocking in fqxtures 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
Benefqts of CI/CD
Tests run even if the backend is down
You can siBlate slow or error conditions easily
Your pipelines are faster and more stable
Best Practices

41. Separate mock logic from core test logic -Use environment flags
(isMock=true) to control mocking -Log actual vs mocked
endpoints
Want support combining mocking
with advanced Playwright features in
real projects?
Common Challenges and How to Handle
Challenge Solution
Dynamic tokens in headers Capture and reuse them
Overusing mocks Use real APIs where possible
Debugging failures
Log request URL, headers, and mocked
response
Real-World Use Cases
Case 1: Mocked payment API to test success/failure flow
Case 2: Replaced slow user profqle API to speed up login tests
Case 3: SiBlated GraphQL API when the backend was under
maintenance
Prerequisite
Place this at the top of your fqle:
Talk to our experts

42. 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

43. 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

44. 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:

45. Case 2: Replaced slow user profqle API to
speed up login tests
Scenario:
We have a login flow where the app fetches user profqle details from
/user/profqle 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/profqle’ request.
Respond instantly with fake data ({“name”: “QA Tester”}).
Assert that the frontend shows: “Welcome, QA Tester”

46. Steps:
Step 1: Create an HTML fqle called profqle.html
Step 2: Playwright Test –
UserProfqleApi_ShouldBeMockedQuickly

47. RouteAsync(“**/user/profqle” – intercepts any request matching
‘/user/profqle’
FulfqllAsync(…) – Responds imediately with { “name”: “QA
Tester” }
GotoAsync(…) – Loads the local HTML page
ClickAsync(…) – SiBlates user clicking “Login”
TextContentAsync(“#welcome”) – Captures the welcome
message
Assert.AreEqual(…) – Confqrms the UI shows the expected result
Output in UI:

48. 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 fqle- graphql.html

49. Step 2: Create playwright test –
MockedGraphQLApi_ShouldReturnStaticUserInfo

50. 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

51. Useful when you’re working on frontend-fqrst development
Ensures CI/CD pipelines don’t break due to backend outages
Best Practices for Network Interception
and Mocking
Use Specifqc Patterns: Avoid intercepting all requests unless
necessary. Use specifqc 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.
SiBlate 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 refqne 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 traffqc into reusable mocks, are poised to redefqne
automation workflows.
Incorporating these practices ensures signifqcant time savings and
improved effqciency in debugging and
test execution across scalable automation frameworks.
Originally Published By:- JigNect Technologies