End-to-end testing with Playwright
From flakiness to the Page Object Model, nine articles on a suite you can trust
E2E suites are not abandoned because they are slow: they are abandoned when the team stops believing their failures. The series starts from the technical reason flaky tests exist at all: the protocol the test uses to talk to the browser. And it ends with a suite that runs in CI, mocks the network, correlates to backend traces, and stays readable as it grows.
E2E suites do not die of slowness, they die of distrust
Tests that pass on the third attempt. sleep(5000) scattered through the code. Suites that run for twenty minutes and fail non-deterministically, always on a different test. The usual explanation is that end-to-end tests are fragile by nature, and that you learn to live with it.
That is not true. The fragility is not a property of end-to-end testing: it is a consequence of how the test talks to the browser. Change that channel and most of the symptoms disappear without touching a single line of test logic.
The moment a suite gets abandoned is not when it becomes slow: it is when the team stops believing its failures. From there on it keeps burning CI time without producing information, and whoever ships learns to hit skip.
This series follows the whole path: from the protocol that produces flakiness to a suite that runs parallelized in CI, mocks the network, correlates to backend traces, and stays readable when the tests number in the hundreds.
What you will learn
- ✓ Understand why auto-waiting removes timing bugs, and what it does not remove
- ✓ Correlate a failed test with the backend trace that made it fail
- ✓ Parallelize in CI with sharding, and know when the bottleneck moves somewhere else
- ✓ Mock the network: from a single endpoint to replaying HAR sessions
- ✓ Diagnose a flaky test instead of adding a retry
- ✓ Organize the suite with the Page Object Model before it becomes unmanageable
Articles in the series
- 01E2E tests aren't fragile. The protocol was. 7 min
Flaky E2E tests are not a discipline problem: it is the protocol the test speaks to the browser. Auto-waiting, WebSocket, parallelisation.
→ - 02From E2E test failure to backend root cause: Playwright + OpenTelemetry 13 min
How to correlate Playwright E2E tests with OpenTelemetry traces to identify the guilty microservice when a test fails
→ - 03Playwright in CI/CD: Sharding, Mobile Testing, and Agent-Driven Automation 10 min
How to integrate Playwright into your CI/CD pipeline with sharding, mobile emulation, and API testing for fast, reliable E2E suites ready for agent-driven automation
→ - 04Playwright: Network Mocking and API Interception for Reliable Tests 12 min
page.route() intercepts requests at browser level: fulfill, continue, abort. Five patterns for mocking APIs, HTTP errors and loading states.
→ - 05Playwright: Mock Fixtures, HAR Replay, and Composition for Scalable Tests 13 min
MockApi fixtures, HAR replay and composition: inline for a single test, fixtures from three up, HAR for flows with too many APIs to mock by hand.
→ - 06Playwright: Visual Regression Testing to Catch Invisible Bugs 13 min
How to use toHaveScreenshot() to catch visual bugs that functional tests miss: masking, mocked states, cross-browser testing, and CI configuration
→ - 07Playwright: Diagnosing and Fixing Flaky Tests 15 min
How to identify the root causes of flaky tests and fix them: Trace Viewer, strategic retry, anti-flaky patterns, and a diagnostic checklist
→ - 08Playwright: Authentication Testing with storageState and Keycloak 13 min
How to handle authentication in E2E tests: storageState to avoid repeated logins, multiple roles, session management, and composition with mocks
→ - 09Playwright: Page Object Model for Maintainable Tests 13 min
How to organize E2E tests with the Page Object Model: reusable classes, Playwright fixtures, composition with mocks, and refactoring guidance
→