Currents

We wrote about why feature flags are one of the sneakiest sources of flaky Playwright tests in CI pipelines. Flags live outside the browser context Playwright controls, so parallel workers end up sharing flag state and causing race conditions that look like infrastructure noise. The article walks through intercepting flag evaluation at the network layer, treating flag state as a declared fixture rather than something tests discover at runtime, and structuring parallel runs so no worker can mess with another's flag context. 👉 Read it here: https://lnkd.in/ebN-mSPh

We published a side-by-side look at running Playwright at scale on GitHub Actions vs GitLab CI. It covers the specific differences in caching, artifact handling, runner specs for Chromium, retry strategies, and billing. Both platforms share one fundamental limitation: they distribute tests statically before execution starts. The article walks through what that costs you and includes a formula to measure when native CI tooling stops being enough. 👉 Read it here: https://lnkd.in/eSkR3BhX

We wrote about how Playwright tests leak sensitive data, and it's usually not from mishandling .env files. The article covers where leaks actually happen: traces capturing auth headers, screenshots with credentials visible on screen, HAR files committed to repos, and fixture annotations printing tokens to reports. It walks through Playwright's built-in controls for scoping what gets captured, sanitizing artifacts before they leave the runner, and what to do if you've already shipped credentials in your test output. 👉 Read it here: https://lnkd.in/esK-M8tv

We wrote about the *Playwright anti-patterns* that show up in almost every test suite once it hits a certain size. It covers shared state between tests, order-dependent execution, fragile selectors, arbitrary timeouts, god fixtures, over-mocking, and configuration mistakes that only surface at scale. Each section explains why the pattern breaks and shows the fix. 👉 Read it here: https://lnkd.in/e4ChKtib

We wrote an article about handling Playwright tests between staging and production — what belongs where, how to configure each, and when production testing isn't worth it. 👉 Read it here: https://lnkd.in/dUMDEhDi

We wrote about why UI refactors keep breaking Playwright tests even when the features work fine. It covers the coupling patterns that make suites fragile and ranks selectors by what actually survives design system changes. There's also a section on structuring page objects so migrations don't cascade into dozens of test failures. 👉 Read it here: https://lnkd.in/dGCtCC_7

We wrote about why Playwright's HTML reporter stops being useful once your test suite grows. The article covers where the native reporter works well, where it breaks down (around 100+ tests), and what teams actually need instead: cross-run history, flakiness detection, worker visibility, and branch-level reliability tracking. We also go into when you don't need to change anything and can keep using native reporting. 👉 Read it here: https://lnkd.in/deFHnt7A

We put together a complete guide to testing authentication with Playwright. It covers: 🔹 Credential anti-patterns you hit at scale 🔹 storageState architecture and per-worker isolation 🔹 Multi-user and multi-role setups 🔹 OAuth mocking vs real provider testing 🔹 Magic links 🔹 SSO 🔹 Multi-tenant isolation 🔹 TOTP-based MFA and session expiry 🔹 Debugging auth failures 🔹 CI/CD secrets management 🔹 Compliance and observability 👉 Read it here: https://lnkd.in/ds_eNa3q

We wrote about the problems that show up when a Playwright suite crosses a few hundred tests. Shared test data starts causing random failures as soon as you parallelize. Retries become a crutch nobody questions. The suite takes so long that developers stop running it locally, and every regression gets discovered in CI 20 minutes after you've moved on to something else. The article covers each of these and a practical roadmap for fixing them.

We put together a guide on network mocking in Playwright, focused on what happens after the initial setup works and the suite starts aging. It covers five levels of mocking from real API calls to schema-validated responses, how mock debt builds up when API contracts change underneath you, and a decision framework for which flows need real integration tests. There's also an eight-week roadmap for retrofitting validation onto an existing mock-heavy suite. 👉 Read it here: https://lnkd.in/gvgQPuE9