Principle:MarketSquare Robotframework browser Network Traffic Observation
Network Traffic Observation
Intercepting and observing network requests and responses triggered by user actions in Robot Framework Browser.
Overview
When testing web applications, it is often necessary to verify that specific API calls are made by JavaScript running on the page in response to user actions (clicks, form submissions, navigation). The Robot Framework Browser library provides the Wait For Response and Wait For Request keywords for this purpose. These keywords intercept network traffic and return structured data about the requests and responses that match specified patterns.
Core Concept
Network traffic observation works by registering a listener on the Playwright page that watches for HTTP requests or responses matching a given pattern. The listener is backed by Playwright's page.waitForRequest() and page.waitForResponse() APIs.
The fundamental principle is that observation must be set up before the triggering action occurs. If a test clicks a button that triggers an API call, the observer must already be listening when the click happens; otherwise, the network event may fire and complete before the observer is registered, causing a timeout.
The Promise Pattern
To handle the timing requirement, Robot Framework Browser uses the Promise To pattern. This pattern allows the test to:
- Start waiting for a network event asynchronously (returns a promise).
- Perform the triggering action (click, type, navigate).
- Wait for the promise to resolve and retrieve the result.
*** Test Cases ***
Verify API Call On Button Click
${promise}= Promise To Wait For Response **/api/submit
Click \#submit-button
${response}= Wait For ${promise}
Should Be Equal As Integers ${response.status} 200
Without the promise pattern, there is a race condition: the Click might complete and the response might arrive before Wait For Response starts listening.
Matcher Types
Both Wait For Request and Wait For Response support three types of matchers:
| Matcher Type | Syntax | Description |
|---|---|---|
| Glob Pattern | Plain string with wildcards | Matches URLs using glob syntax. Supports * (any chars except /), ** (any chars including /), ? (single char), [abc] (character class), {foo,bar} (alternatives).
|
| Regular Expression | Enclosed in / with optional flags |
JavaScript regular expression. Example: /api\/users\/\d+/i. Backslashes must be escaped in Robot Framework (\\).
|
| JavaScript Function | Arrow function or function expression |
Receives the Playwright Request or Response object and returns a boolean. Example: response => response.url().endsWith('json') && response.status() === 200.
|
Important migration note: Before Browser library version 17.0.0, the matcher was always either a regex or JavaScript function, and regex did not require enclosing slashes. Starting from 17.0.0, glob patterns are supported by default, and regex must be enclosed in slashes.
Synchronous vs Asynchronous Usage
Synchronous usage works when the network event is triggered before Wait For Response is called, and the response has not yet completed. This is suitable when there is inherent delay in the response:
Click \#delayed-request
Wait For Response **/api/slow-endpoint timeout=30s
Asynchronous usage (the Promise pattern) is the safer approach for all scenarios:
${promise}= Promise To Wait For Response **/api/endpoint timeout=60s
Click \#trigger-button
Click \#next-step
${response}= Wait For ${promise}
The asynchronous approach is recommended because it eliminates race conditions between action execution and response interception.
Response Data Structure
Wait For Response returns a DotDict with:
| Attribute | Type | Description |
|---|---|---|
status |
int |
HTTP status code. |
statusText |
str |
Human-readable status text. |
body |
str | Response body (auto-parsed as JSON if applicable). |
headers |
dict |
Response headers as a dictionary. |
ok |
bool |
True if status is 200-299.
|
url |
str |
The request URL. |
request |
dict |
Sub-dictionary with method, headers, and postData.
|
Wait For Request returns the request URL as a string (wrapped in DotDict if possible).
Use Cases
- API verification: Confirm that a UI action triggers the correct backend API call with expected parameters.
- Response validation: Check that the server response to a UI-triggered request contains expected data.
- Error monitoring: Detect failed API calls (status >= 400) triggered by page interactions.
- Performance observation: Measure whether API calls complete within expected timeframes.