Playwright in CI

Playwright is a browser automation library that drives Chromium, Firefox, and WebKit through a single API. What separates it from the previous generation of end-to-end tools is not the API surface, it is two defaults: auto-waiting locators and web-first assertions that retry until a timeout. Together they remove the most common source of hand-written flakiness, which is a test that asserted before the page was ready.

That does not make a Playwright suite automatically reliable. It moves the failure modes somewhere else, into locator strategy, fixture scope, worker isolation, and CI configuration. This topic covers the work that keeps a suite fast and trustworthy after the first fifty tests, when the defaults stop carrying the whole load.

Testland's position: the framework choice matters far less than the suite architecture built on top of it. A disciplined Selenium suite beats an undisciplined Playwright suite, and most migration projects that expected a reliability win from the tool alone got a rewrite of the same problems in new syntax.

Getting a project to first green

A new Playwright project needs four decisions before the first test: TypeScript or JavaScript, which browser projects to run, where the base URL comes from, and how authentication state is established. Getting authentication right early is the one that saves the most time later, because a suite that logs in through the UI on every test spends most of its runtime on a code path it is not testing.

Setting up Playwright with TypeScript from scratch walks the project creation, config, first test, and CI wiring end to end.

Locators are the durability decision

Selector strategy determines how much maintenance a suite costs over its life. CSS class chains and nth-child positions break on every refactor. Role-based and label-based locators break when the accessible name changes, which is a meaningful change worth breaking on.

Playwright's getByRole, getByLabel, and getByTestId exist in that priority order for a reason: the first two assert something a user can perceive, and the third is an explicit contract between the test and the markup. Reaching for raw CSS is the point where a suite starts accumulating the maintenance debt that eventually gets it deleted.

Speed is a reliability feature

A 4 hour suite and a 30 minute suite are not the same suite at different speeds, they are different products. Engineers route around the slow one, merge without waiting, and discover failures after the fact. Fast feedback is what makes the suite part of the development loop rather than an audit that happens later.

Sharding across CI machines, running browser projects in parallel, caching browser binaries, and reusing authentication state are the four levers that matter most, and they interact: sharding multiplies the cost of a slow global setup across every shard. How to set up GitHub Actions for test automation covers triggers, dependency caching, the browser matrix, sharding, and artifact upload with a copy-ready workflow.

When the flakiness is yours, not the framework's

Auto-waiting handles element readiness. It does not handle a test that depends on data another test created, a worker that shares a database row, a fixture scoped too broadly, or an assertion on a value the application legitimately renders twice.

Flaky Playwright tests: five root causes and fixes covers the failure modes specific to this framework, including the limits of auto-wait and the non-retrying assertion forms that quietly reintroduce races. The general diagnosis and quarantine machinery lives under flaky tests.

Choosing between frameworks

Playwright is not the correct answer for every team. Cypress has a debugging experience that some teams weigh above cross-browser coverage, and Selenium remains the only option for stacks locked to its language bindings or an existing grid investment.

Playwright vs Cypress vs Selenium: 2026 edition compares browser architecture, parallelism costs, and AI-assisted test features, and lands on a recommendation by team shape and language rather than declaring a single winner.

Tooling

qa-web-e2e packages the framework wrappers as installable skills, including playwright-testing for authoring and flakiness remediation. web-e2e-framework-selector reads an existing project and recommends one framework; playwright-codegen-reviewer refactors raw codegen output into page objects with accessibility-first locators, which is the step most teams skip; and spec-to-e2e-test-scaffolder turns a user story into a test skeleton without inventing selectors.

CI wiring lives in qa-ci-integration, including GitHub Actions test jobs and the conventions that keep sharded runs reportable.

What this topic does not cover

Component testing, visual regression, and accessibility assertions can all be driven from Playwright, but they are separate disciplines with their own baselines and gates. Mobile app automation is out of scope entirely: Playwright drives mobile browsers, not native applications.