Playwright
Driving Chromium, Firefox and WebKit from one API: auto-waiting locators, isolated contexts, a fixture-based runner and traces. Asked because it is the default choice for new browser suites.
on this pageshowhide
explore
- Browsers and Contexts36 questions
- Runtime Startup11 questions
- Session Isolation10 questions
- Emulated Environment15 questions
- Locators and Auto-Waiting59 questions
- Query Builders20 questions
- Narrowing a Match9 questions
- Interaction Gating15 questions
- Acting on a Match15 questions
- Assertions29 questions
- Automatic Retrying9 questions
- Programmable Checks9 questions
- Snapshot Matching11 questions
- Fixtures and Test Config41 questions
- Injected Setup16 questions
- Runner Settings15 questions
- Signed-In State10 questions
- Network Interception32 questions
- Request Control21 questions
- Traffic Observation11 questions
- Tracing and Debugging24 questions
- Recorded Output14 questions
- Live Surfaces10 questions
- Run Orchestration33 questions
- Division of Work14 questions
- Failure Controls9 questions
- Pipeline Handoff10 questions
- Isolated Component Runs14 questions
- Mount and Update5 questions
- Props and Callbacks5 questions
- Limits of a Mount4 questions
- Positioning and Migration19 questions
- Driving Model Contrasts5 questions
- Language Surface Reach5 questions
- Moving an Existing Suite5 questions
- Choosing Between Runners4 questions
questions
287 · 9 sectionsWhy would a Playwright test call page.clock.install instead of page.clock.setFixedTime?
basics
~10 spage.clock.setFixedTime only pins what Date.now and new Date report; timers keep running on real time. page.clock.install replaces the whole timer stack, so the test can pause, tick or jump the page's clock.
In Playwright, what does spreading `devices['iPhone 15']` into a project's `use` block actually configure?
basics
~20 sA device descriptor is a bundle of browser context options under one name. Spreading it sets viewport, screen, userAgent, deviceScaleFactor, isMobile and hasTouch together, plus defaultBrowserType, which tells the test runner which engine to launch.
Why does Playwright download its own Chromium, Firefox and WebKit builds instead of driving your installed browsers?
basics
~20 sPlaywright pins a patched build of each engine to its own release, so every machine runs an identical browser. Its WebKit is built from WebKit sources rather than Safari, and its Chromium is not the Chrome you have installed.
In Playwright, what does the headless option on browserType.launch() control, and what is its default?
basics
~20 sPlaywright's headless launch option decides whether the browser draws a visible window. It defaults to true, so launch() starts an invisible browser; passing headless: false opens a real window you can watch a failing flow in.
In Playwright, which browser context options set the page's language and time zone?
basics
~10 sPlaywright's locale and timezoneId context options. locale sets navigator.language, the Accept-Language header and Intl formatting; timezoneId sets the IANA zone that Date and Intl.DateTimeFormat resolve to.
In Playwright, how does locator.setInputFiles() attach a file without the OS picker?
basics
~20 sPlaywright sets the file input's file list directly through the browser protocol instead of driving the native dialog. Pass one path, several paths, an in-memory buffer object, or an empty array to clear the selection.
In Playwright, how does locator.fill() differ from locator.pressSequentially() in what the page receives?
basics
~20 slocator.fill() focuses the field, selects any existing text and replaces it in one insertion, firing a single input event. locator.pressSequentially() sends keydown, keypress, input and keyup per character and does not clear the field first.
In Playwright, what does locator.press('Control+Enter') send to the page, and how are key names resolved?
basics
~10 slocator.press focuses the matched element, holds Control, presses and releases Enter, then releases Control. The argument is one logical key name or a single character, with modifiers joined by plus signs.
In Playwright, what must be true of an element before locator.click() actually clicks it?
basics
~20 sPlaywright retries a set of actionability checks until they all pass or the call times out: the element must be visible, stable in position, able to receive pointer events at the click point, and enabled.
In Playwright, what does locator.filter({ hasText: 'Blocked' }) return compared with the locator it was called on?
basics
~20 sA new locator matching the same kind of elements, minus the ones whose subtree lacks that text. The original locator is untouched, the match stays on the outer elements, and a string is matched case-insensitively as a substring.
In Playwright, what does expect(locator).toMatchAriaSnapshot() compare, and what does it ignore?
basics
~20 sIt compares an element's accessibility tree, meaning the roles, accessible names and a few ARIA states of its non-hidden nodes, against a YAML template. It ignores pixels, CSS, tag names, class names and hidden nodes.
In Playwright, what happens the first time expect(page).toHaveScreenshot() runs and no reference image exists?
basics
~20 sPlaywright captures the page, writes that capture to the snapshots folder as the new reference image, and still fails the test. A later run, or an automatic retry, compares against the file just written and passes.
In Playwright, what does expect.soft() do that a plain expect() does not?
basics
~10 sA soft assertion records its failure and lets the test keep running, while a plain expect throws and stops the test at that line. Both end with the test reported as failed.
In Playwright, what happens if you forget to await expect(locator).toBeVisible()?
basics
~20 sPlaywright's web-first matchers return a promise. Without await, the test body runs on and the test finishes before the matcher decides anything, so the assertion can never fail it — the error is dropped or blamed on a later test.
In Playwright Test, what do you get when a test destructures the page fixture?
basics
~20 sPlaywright Test builds a brand-new BrowserContext for that one test and hands back the single page opened inside it. The runner creates it before the test body and closes it afterwards, so no test inherits another test's page.
In Playwright, what does the await use(value) call do inside a test.extend fixture?
basics
~20 sIt hands the fixture's value to the test and pauses the fixture there. Everything written above the call is setup; everything below it is teardown, which runs once the test finishes, whether it passed or failed.
What does Playwright's webServer config option do before the first test runs?
basics
~10 sPlaywright's webServer option spawns a command before the suite and waits until the url or port it names answers, then runs the tests and stops the process it started when the run ends.
In Playwright, how do you run one spec as an admin and another as a read-only staff user?
basics
~20 sCapture one storage-state file per role, then choose the file explicitly: a project per role carrying use.storageState in the config, or test.use with that role's file at the top of a spec or describe block.
In a Playwright config, what does the `projects` array do?
basics
~20 sThe projects array lists named run variants, each with its own use options and file filters. Playwright runs every matching spec once per project, so one test yields one result per project, and --project=<name> runs a single variant.
In Playwright, what does the built-in request fixture let a test do without opening a page?
basics
~20 sPlaywright's request fixture is an APIRequestContext, a per-test HTTP client. It sends get, post, put, patch, delete or fetch calls straight to the server, with no browser page and no navigation, honouring config options such as baseURL.
In Playwright, how do you capture a page's API response and assert on its body?
basics
~10 sCreate the wait first with page.waitForResponse, matching by URL glob, RegExp or predicate, then trigger the action and await the promise. The resolved Response exposes status(), headers() and json() for assertions.
In Playwright, how does route.fulfill() answer a request without it reaching the network?
basics
~20 sroute.fulfill() completes a Playwright route by returning a response the test supplies, so the browser never contacts the real server. You set the status, headers and body, or pass a JSON object or a file path instead.
In Playwright, what does browserContext.routeFromHAR() do to the requests a page makes?
basics
~20 sIt installs a route that answers matching requests from a previously recorded HAR archive instead of the real server, so the test replays saved traffic. Requests the archive does not contain are aborted by default.
In Playwright, what URL matchers can you pass to page.route() when intercepting a request?
basics
~20 sPlaywright's page.route() accepts three matcher forms: a glob string, a RegExp tested against the whole URL, or a predicate function receiving a parsed URL object. Only the URL is matched; method and headers are checked inside the handler.
What does `npx playwright codegen <url>` open, and what does it produce?
basics
~20 sPlaywright's codegen command opens a browser plus a recorder window, transcribes every click, keystroke and navigation into runnable test code as you go, and hands back a first draft you copy or save with -o.
What does npx playwright test --ui give you that a plain headed run does not?
basics
~20 sPlaywright's UI mode opens a watching test explorer: pick tests, re-run them on save, and step through a recorded timeline with before and after DOM snapshots, plus a Pick locator button. A headed run only shows the browser flying past.
In Playwright Test, what does the screenshot: 'only-on-failure' option capture, and where does the file land?
basics
~20 sThe runner itself photographs every page open in the test at the moment the test ends failed, and only then. Each PNG is written into that test's folder under outputDir, test-results by default, and attached to the result.
In Playwright, what does the config option trace: 'on-first-retry' record?
basics
~10 sPlaywright records a trace only while a test runs its first retry. The original failing attempt is never traced, and if the project allows no retries, no trace is produced at all.
How do you open a Playwright trace zip to step through a failed run?
basics
~10 sRun npx playwright show-trace path/to/trace.zip to open it in Playwright's Trace Viewer, or drag the same zip onto trace.playwright.dev, which renders it in the browser with nothing installed.
In Playwright, what does `npx playwright install --with-deps` do that plain `npx playwright install` does not?
basics
~20 sIt also installs the operating-system packages the browsers link against, using the system package manager, before downloading them. Plain install only downloads the browser binaries, which then fail to launch on a bare Linux runner.
In Playwright, what does the fullyParallel config option change about test scheduling?
basics
~20 sPlaywright runs test files in parallel but keeps tests inside a file in order in one worker. Setting fullyParallel true schedules every individual test independently, so tests in the same file can also run at the same time.
In Playwright, how do you run one suite with several reporters at once and give each its own options?
basics
~20 sSet the reporter config option to an array of entries, each a reporter name plus an options object - for example list, junit with an outputFile, and html. The command line --reporter takes comma-separated names but carries no options.
In Playwright, what does setting retries: 2 in playwright.config.ts do to a failing test?
basics
~20 sPlaywright re-runs a failing test up to two more times, so retries: 2 allows three runs in all. Only the failing test re-runs, and one that passes on a later attempt is reported as flaky rather than failed.
What does Playwright's --shard=1/4 flag do to the set of tests a run executes?
basics
~20 sPlaywright splits the selected tests into four disjoint groups and runs only the first. Each shard is an independent run on its own machine, so all four have to be executed before the suite is covered.
In Playwright, which parts of an application does a component test leave untested?
basics
~20 sA Playwright component test starts no application server, mounts no router and assembles no page. It proves one component in a bare harness, so API behaviour, navigation between screens and interactions between components stay uncovered.
In a Playwright component test, what does the mount fixture hand back after it renders a story?
basics
~20 sThe mount fixture resolves to a Locator pointing at the rendered component's root element. You drive and assert on it like any other locator, and the same handle also exposes update and unmount for that instance.
In a Playwright component test, why can't you pass an onSelect callback in mount's props?
basics
~20 sPlaywright sends mount's props across a process boundary into the browser, so only plain serialisable data survives. A function carries behaviour that cannot be transferred, so callbacks belong in the story file, not in the props object.
In Playwright, what does mounting in a real browser engine catch that a simulated DOM cannot?
basics
~20 sA Playwright component test renders in Chromium, Firefox or WebKit, so real CSS, real layout and real hit-testing apply. A simulated DOM in Node computes no boxes, so clipping, overlap and interception bugs stay invisible there.
In Playwright component tests, how does calling update on a mounted component differ from mounting it again?
basics
~20 supdate re-renders the component already on the page with new props, so its internal state — an open menu, scroll position, focus — survives. Mounting again builds a fresh instance and throws all of that away.
How does Playwright's test process control the browser it automates?
basics
~20 sPlaywright test code runs in its own Node process, outside the browser. The library launches a browser build it ships itself and drives it over one long-lived connection that carries every command and every event for the whole session.
In a Python Playwright suite, what does the pytest-playwright page fixture give each test?
basics
~20 sThe pytest-playwright plugin's page fixture gives every test a fresh Playwright Page in its own new BrowserContext, opened on a session-scoped browser and closed automatically when the test ends, so cookies and storage never leak between tests.
Which browser targets does Playwright leave uncovered when you weigh it against an existing browser grid?
basics
~20 sPlaywright 1.63 ships Chromium, Firefox and WebKit, and drives locally installed Chrome or Edge through channels. It cannot drive Internet Explorer, arbitrary historical engine builds, or real phones, so those targets still need a grid or a device cloud.
Why can Playwright retry an action's readiness checks without paying a round trip per attempt?
basics
~20 sBecause the retrying happens on the browser side. One command crosses the already-open connection, and Playwright's browser-side code re-resolves the element and re-checks readiness in a loop until the action succeeds or that command's timeout expires.
Which parts of Playwright do the Python, Java and .NET bindings get, and which are JavaScript-only?
basics
~20 sPlaywright's browser automation library, covering browser, context, page, locators, assertions, routing and tracing, ships in Python, Java and .NET. The @playwright/test runner does not: projects, retries, sharding, custom fixtures, component mounting and its reporters stay JavaScript-only.