Principle:MarketSquare Robotframework browser API Test Context Setup
API Test Context Setup
Configuring browser contexts specifically for API testing rather than UI testing in Robot Framework Browser.
Overview
The Robot Framework Browser library allows test authors to configure browser contexts for API testing in addition to traditional UI testing. While a browser context in UI testing focuses on viewport dimensions, device emulation, and visual properties, an API testing context emphasizes HTTP-level configuration: base URLs, authentication headers, credential handling, and certificate management. The same New Context keyword serves both purposes, but the parameter selection differs substantially.
Core Concept
A browser context in Playwright is an isolated browser session with its own cookies, cache, and configuration. When repurposed for API testing, the context provides an execution environment where HTTP requests can be issued via the HTTP keyword, inheriting all context-level network settings. This means that once a context is configured with a baseURL and authentication headers, all subsequent HTTP calls within that context automatically use those settings.
The key insight is that the browser context is not merely a container for UI pages -- it is a fully configured HTTP client environment. Setting up a context for API testing means focusing on the network transport layer rather than the rendering layer.
Key Configuration Parameters
The following parameters on New Context are most relevant for API testing scenarios:
| Parameter | Type | Purpose in API Testing |
|---|---|---|
baseURL |
str |
Sets a base URL for all relative URL references in HTTP, Go To, Wait For Request, Wait For Response, and Wait For Navigation keywords. This allows tests to use short relative paths like /api/users instead of full URLs.
|
extraHTTPHeaders |
dict[str, str] |
A dictionary of additional HTTP headers sent with every request from the context. Commonly used for API keys, authorization tokens, content-type declarations, and custom tracing headers. |
httpCredentials |
HttpCredentials |
Credentials for HTTP Basic Authentication. Includes username, password, and optionally origin to restrict which hosts receive the credentials. Values are resolved internally so they do not appear in Robot Framework logs.
|
ignoreHTTPSErrors |
bool |
When set to True, HTTPS certificate validation errors are suppressed. Essential when testing against services with self-signed certificates or local development environments without proper TLS configuration.
|
clientCertificates |
list[ClientCertificate] |
Specifies client certificates for mutual TLS (mTLS) authentication. Each entry requires an origin, a certificate path (PFX or PEM), and optionally a passphrase.
|
proxy |
Proxy |
Network proxy settings for the context. Useful when API traffic must route through a corporate proxy or when testing proxy-aware applications. |
storageState |
str |
Restores a previously saved storage state (cookies, local storage). Enables reusing authentication tokens obtained from a login flow without repeating the login for each API test. |
baseURL Resolution
The baseURL parameter uses the JavaScript URL() constructor for URL resolution. This means standard relative URL semantics apply:
- With trailing slash:
baseURL=http://localhost:3000/foo/and navigating to./bar.htmlresolves tohttp://localhost:3000/foo/bar.html. - Without trailing slash:
baseURL=http://localhost:3000/fooand navigating to./bar.htmlresolves tohttp://localhost:3000/bar.html(thefoosegment is replaced). - Absolute path: Navigating to
/bar.htmlalways resolves tohttp://localhost:3000/bar.htmlregardless of trailing slash.
This behavior is especially important in API testing because most API endpoints use absolute paths like /api/v1/users.
Difference from UI Testing Configuration
When setting up a context for UI testing, the focus is on parameters such as viewport, deviceScaleFactor, colorScheme, isMobile, hasTouch, geolocation, and permissions. For API testing, these parameters are typically left at their defaults or are irrelevant. The API testing context prioritizes:
- Network identity: Who the client is (credentials, headers, certificates).
- Network routing: Where requests go (baseURL, proxy).
- Error tolerance: How strictly to validate connections (ignoreHTTPSErrors).
- Session state: What cookies and tokens to carry (storageState, extraHTTPHeaders).
Session Sharing
Because the HTTP keyword executes requests within the browser context using the page's JavaScript fetch() API, API requests share cookies and session state with any pages opened in the same context. This enables a powerful testing pattern:
- Log in through the UI (filling forms, clicking buttons).
- Save the resulting session state using
Save Storage State. - Open a new API-focused context with
storageStateto reuse the session. - Execute API calls with the
HTTPkeyword, inheriting the authenticated session.