Playwright Interview Questions

"Playwright controls the browser from outside through low-level protocols, which gives it fast, reliable control of Chromium, Firefox and WebKit, and it ships auto-waiting, isolated contexts, network interception and a trace viewer as first-class features. Selenium speaks WebDriver, which is a standard with the broadest support but leaves waiting and tooling to you. Cypress runs in the browser with the app, which makes debugging pleasant but limits things like multiple tabs, and it is JavaScript only."

"Every action in Playwright first waits for the element to be ready: attached to the DOM, visible, not animating, enabled, and not covered by something else. Only then does it perform the click or fill. If those conditions are never met within the timeout, the test fails with a message saying which check failed. That is why I almost never write an explicit wait or a sleep."

"A locator is not an element; it is a recipe for finding one that is re-run every time I act on it or assert against it, so it cannot go stale. I prefer getByRole, getByLabel and getByText because they describe the page the way a user sees it, so a CSS class rename does not break the test, and they double as an accessibility check. If a locator matches more than one element, an action fails loudly, which I like, because ambiguous selectors are bugs waiting to happen."

"A browser is the heavy process; a context is a lightweight isolated profile inside it with its own cookies, local storage and permissions; a page is a tab in that context. Playwright Test gives every test a brand-new context, so one test cannot pollute another, and because contexts are cheap that isolation costs almost nothing. It also lets me simulate two users in one test by opening two contexts."

"I create a setup project with one test that signs in and calls storageState to write the cookies and local storage to a file. The real test projects declare a dependency on that setup and point their storageState option at the file, so every new context starts logged in without touching the login page. For different roles I keep one state file each and choose it per project or per test."

"Playwright Test starts several worker processes and hands them test files; with fullyParallel it splits individual tests too. What breaks is anything shared: two tests editing the same user, tests that assume the previous one ran, or a fixed file path. I fix that with unique test data per test, one account per worker using a worker-scoped fixture, and I reserve serial mode for the rare flow that genuinely depends on order."

"A trace records the whole test: each action with a DOM snapshot before and after it, network requests, console output and a filmstrip. In CI I record traces on the first retry, so a green run pays nothing and a flaky failure still gets captured. When something fails I open the trace, jump to the failing action and inspect the live DOM at that moment, which usually shows the cause immediately."

"A fixture is setup and teardown wrapped around a value the test asks for by name. I create one with test.extend: the function builds the thing, for example a logged-in page or a seeded database row, calls use with it so the test runs, and whatever comes after use is the teardown. Test-scoped fixtures rebuild per test; for expensive resources like a server or an admin account I use worker scope so it is built once per worker. Tests then declare only what they need, which keeps them short and independent."

"I register a route on the page or context for a URL pattern and decide per request: fulfil it with a fixed JSON body, let it continue with modified headers, or abort it to simulate a failure. For bigger surfaces I record a HAR once and replay it, which makes UI tests deterministic and fast. I still keep a thin layer of unmocked tests so a real API change is caught somewhere."

"First I get evidence: traces on retry in CI, then I look at the exact action that failed and what the DOM looked like. Most of the time it is a check that ran once, like reading text and comparing immediately, which I replace with a retrying expect. The next most common causes are a race with a request, which I fix by waiting for that response, and shared test data across parallel workers, which I fix with unique data. I keep retries on in CI as a safety net, but a test that needs them is still a bug to me."

"expect with a locator matcher keeps polling until the condition is true or the timeout runs out, so it naturally waits for the app to catch up. isVisible answers instantly about this exact moment, and if I put that into a normal expect the assertion races the page and fails randomly. So I assert with locator matchers like toBeVisible, toHaveText and toHaveCount, and I only call the instant methods when I need to branch."

"In the config I define projects: one for Chromium, one for Firefox, one for WebKit, and mobile projects that use the built-in device descriptors for viewport, user agent and touch. Every pull request runs one desktop project to stay fast, and the full matrix runs nightly. I am clear with the team that emulation covers layout and behaviour, not real device quirks."

"For an iframe I use frameLocator to scope into it and then use ordinary locators inside. For a link that opens a new tab I first create a promise waiting for the popup event, then click, then await the promise to get the new page object and work with it like any page. The order matters: the listener has to exist before the click or the event is gone."

"toHaveScreenshot takes a screenshot and compares it with a baseline image committed to the repo, with a tolerance for tiny differences. Baselines are stored per browser and platform, and I regenerate them deliberately with the update flag when the UI changes. The main trap is that fonts and anti-aliasing differ between a laptop and CI, so I create baselines inside the same container image the pipeline uses, and I mask timestamps and other moving parts."

"Yes, but a lighter version. Grouping a page's locators and common flows in a class still makes tests read like a story and keeps changes in one place. What I avoid is the old heavyweight pattern with inheritance and wrappers around every method, because Playwright's locators and fixtures already handle waiting and setup. I usually expose page objects as fixtures so a test just asks for the page it needs."

"I run the suite in the official Playwright container so browsers and fonts match everywhere, headless, with traces on first retry. The runner uploads the HTML report and a machine-readable report for the CI dashboard. To keep it fast I shard the suite across several machines and merge the blob reports into one, cache the browser downloads, and run the full cross-browser matrix nightly rather than on every push."

"For uploads I call setInputFiles on the input element with a fixture file path, or with a buffer if I want to generate the file in the test; if the app uses a custom picker I wait for the filechooser event instead. For downloads I start waiting for the download event, click the button, and then save the file and check its name and contents. Both are a few lines and need no plugins."

"An element handle is a pointer to a specific node that existed when I fetched it; if the framework re-renders that part of the page, my handle is stale and actions on it fail or hit the wrong thing. A locator is just the query, re-run at the moment of each action or assertion, so it always finds the current element and gets auto-waiting for free. That is why the docs steer everyone to locators."

"Playwright has a request fixture for plain HTTP calls, so I can write pure API tests with the same runner and reports. More often I use it to prepare state: create the order through the API in one call, then open the page and check it renders, which is much faster than clicking through a checkout. If the API needs the same session as the browser I create the request context from the browser context so the cookies are shared."

"Our checkout suite failed randomly and people had stopped trusting it. Traces showed most failures came from tests reading a price the moment the page loaded, before a currency call returned. I replaced the instant checks with retrying assertions, added a wait for that specific response where the flow depended on it, and moved test data to unique accounts per worker. The suite went from failing several times a day to essentially stable, and the team turned required checks back on."