Playwright

The architecture is the feature list

Your test runs in its own process. It opens one persistent connection to a browser it launched, and every instruction and every event travels over that connection. That is the whole design, and it is worth understanding before any API, because each of the tool’s well-known properties turns out to be a consequence of it rather than a separate piece of engineering.

Because the driver sees browser state directly rather than through the page, it can inspect an element before acting on it and wait until acting makes sense. Because everything crosses one wire, the whole run can be recorded and replayed afterwards. And because the isolation unit is a browser context — a private cookie jar and storage inside an already-running browser — a clean session costs milliseconds instead of a browser launch, which is what makes real parallelism affordable.

Auto-waiting, and why it removes most flakiness

The single largest cause of unreliable browser tests is a test acting before the application is ready: the button exists in the DOM but is still covered by a loading overlay, or it is mid-animation, or React has rendered it but not yet attached the handler. Older tools answered this with sleeps and manual waits, which is a guess dressed up as code. Playwright answers it by checking, before every action, that the element is in a state where acting makes sense.

The second half of the model is the locator. A locator is not an element — it is a description of how to find one, re-resolved every time it is used. That distinction is what makes the checks above possible on a page that re-renders underneath you: the same locator re-finds the current element rather than holding a reference to a node that no longer exists. Assertions work the same way, retrying until the condition holds or the timeout expires, which is why an assertion about text that arrives after a network response needs no wait around it.

Isolation, fixtures and getting a suite to finish in minutes

Every test gets a fresh browser context by default, so there is no shared cookie, no leftover local storage and no order dependency between cases. This is the quiet reason suites written here stay stable as they grow: the most common source of "it passes alone but fails in the suite" is removed by the default rather than by discipline.

• Sign in once, reuse everywhere

  Authenticate in a setup step, save the storage state to a file, and have every test start already signed in. Removes the slowest and most repeated five seconds in the suite.

• Fixtures instead of setup code

  A fixture is a named thing a test asks for — a signed-in page, a seeded order, an API client. It is built on demand and torn down after, so tests declare what they need instead of arranging it.

• Workers, not threads

  Files run in parallel across worker processes, each with its own browser. The practical limit is usually your test data, not your CPU.

• Sharding across machines

  The same suite splits across CI machines by index, and the reports merge afterwards. This is how a forty-minute suite becomes an eight-minute one without deleting anything.

Two capabilities beyond the browser are worth knowing because they change what belongs in the suite at all. Playwright can make API requests directly, in the same test and sharing the same session, so a case can create its fixture data over the API in fifty milliseconds and then check one thing in the UI, rather than clicking through four screens to arrive at the state it wanted. And it can intercept network traffic, so a third party that is slow, rate-limited or unavailable in CI can be replaced at the boundary without touching application code.

What to turn on so a CI failure is diagnosable

The expensive part of an end-to-end failure is never the failure — it is the hour spent trying to reproduce it on a laptop where it does not happen. The trace is the answer to that, and it is the one setting worth getting right before anything else.

• Record a trace on first retry in CI. It captures a DOM snapshot before and after every action, the network log, the console and a video, and opens as an interactive timeline you step through locally.
• Keep retries at one, not three. One retry plus a trace tells you whether the failure is real; three retries tell you nothing and turn a genuine intermittent bug into a green run.
• Use the watch-and-inspect mode while writing tests, where the run pauses, the locator under the cursor is highlighted, and you can try a different one against the live page.
• Treat generated code as a draft. Recording a flow produces working selectors fast, and they are almost always more brittle than the ones you would choose deliberately.

Where it does not help, and how it compares

Playwright is the reasonable default for new browser test suites in 2026, and defaults deserve their caveats stated plainly rather than discovered in month three.

• WebKit is not Safari. It is the same engine, without Apple’s browser around it, so it catches rendering and API differences but not everything specific to the shipped Safari build.
• Mobile emulation is viewport, user agent and touch — not a real device. It finds layout problems and will not find a bug in a real mobile browser or in a native app.
• It does not test native desktop or mobile applications, and it is not a load testing tool, however tempting a hundred parallel contexts look.
• It makes flaky tests less likely; it does not make a badly chosen suite good. Four hundred end-to-end cases are wrong here for exactly the same reasons they are wrong anywhere else.

Anti-patterns worth naming

• Adding explicit waits "just in case" on top of auto-waiting, which slows the suite and hides the real timing question.
• Selecting by CSS class or DOM position because the recorder generated it, which turns every redesign into a day of test repair.
• Reusing one context across tests to save time, which reintroduces the order dependency the tool was designed to remove.
• Raising retries until the pipeline is green, which converts real intermittent defects into passing runs.
• Moving unit-level logic into browser tests because the tooling is pleasant, which is the most expensive way to be thorough.

When to use it

Related pages

• QACypressCypress is a browser test runner that made one decision no other browser tool made: it runs the test inside the browser, in the same tab and the same event loop as the application. That is why it has the debugging experience it does — you can watch a run step by step and inspect the page at any command — and it is also why certain things are awkward or impossible. This page is about that single trade, the command queue and retry model that follow from it, and how to decide whether the trade is right for your suite.
• QASeleniumSelenium is a browser automation toolkit, and it is older than most of the applications it tests — the reason it is still here is not inertia. It is a W3C standard with libraries attached: your test speaks a published protocol, browser vendors implement the other end, and that arrangement gives you something no single-vendor tool offers — any language, any real browser, on machines you control. This page covers the protocol, the waiting model people get wrong, Grid, and an honest answer to when you should still choose it.
• QAEnd-to-end testingAn end-to-end test walks the assembled system the way a person would: through the real interface, across every service, against real configuration, to a real outcome. It is the only level that can prove the parts hold together — and it is also the slowest, the most expensive to maintain and the most likely to fail for reasons that have nothing to do with your change. Both halves of that sentence are true at once, which is why the right number of E2E tests is small rather than zero.