Build fluency with Playwright's test isolation vocabulary — BrowserContext sessions, storageState for auth reuse, page.route() for network interception, test.use() fixture overrides, and sharding for CI parallelism.
0 / 5 completed
1 / 5
What is a BrowserContext in Playwright and why is it useful for testing?
BrowserContext provides a lightweight isolated browser session. Each context has independent cookies, localStorage, IndexedDB, and service workers. Multiple contexts can run in parallel within a single browser instance, enabling parallel test execution without state leakage between tests.
2 / 5
What does storageState do in a Playwright BrowserContext?
storageState serialises a context's cookies and localStorage to a JSON file (await context.storageState({ path: 'auth.json' })). Tests can then reuse this file to start already authenticated, dramatically speeding up test suites by avoiding repeated login flows.
3 / 5
What is page.route() used for in Playwright?
page.route() intercepts network requests matching a pattern. The handler receives a Route object and can call route.fulfill() to mock a response, route.abort() to simulate failure, or route.continue() to pass through. This is essential for testing error states and offline scenarios.
4 / 5
What does test.use() do in a Playwright test file?
test.use() customises fixture values for a test scope. For example test.use({ storageState: 'auth.json' }) at the top of a spec file makes every test in that file start with the saved authentication state, without modifying the global config.
5 / 5
How does Playwright sharding speed up CI test runs?
Sharding in Playwright is invoked with --shard=1/4 (run shard 1 of 4). Each CI job gets a unique shard index and runs only its portion of the test suite. Combined with merge-reports, the results from all shards are consolidated into one HTML report.