Top Playwright Interview Questions: JavaScript, TypeScript, and AI-Powered Testing

Playwright is a browser automation framework developed by Microsoft that communicates directly with browser engines rather than relying on the WebDriver protocol used by Selenium. This enables built-in auto-waiting, easy parallel test execution, and native support for Chromium, Firefox, and WebKit through a single API.

Playwright supports Chromium, Firefox, and WebKit, covering the engines behind Chrome, Edge, Firefox, and Safari, all from the same test code.

Auto-waiting means Playwright automatically waits for an element to become actionable, visible, enabled, and stable, before interacting with it, removing a major source of flaky tests common in older automation tools that require manual wait logic.

Yes. Playwright can emulate mobile viewports, touch input, and device characteristics using its built-in device descriptors, without requiring a real device or separate mobile testing tool.

getByRole() first, since it depends on accessibility semantics rather than markup. Then getByText() and getByLabel(), followed by CSS selectors, with XPath as a last resort. The full reasoning behind this order, along with real examples, is covered in the Playwright locators tutorial.

Because it targets an element by what it is and what it represents to a user, not by class names or DOM structure, both of which change far more often during a redesign than an element’s accessible role.

Through frameLocator(), which first targets the iframe, then allows a normal locator to be chained inside it, since elements inside an iframe are not reachable through the page’s main locator directly.

Yes. Playwright automatically pierces open shadow roots, so most shadow DOM elements can be located the same way as regular elements, without special syntax.

The Page Object Model separates how a test interacts with a page from the test logic itself, wrapping locators and actions inside a class. This means a single UI change only requires updating one file, not every test that touches that page. A full working example is covered in the Page Object Model tutorial.

No. Page objects should expose actions and state. Assertions belong in the test file, keeping responsibilities clean and page objects reusable across different test scenarios.

A base page class holds behavior shared across multiple pages, such as navigation or screenshots, so individual page objects can extend it instead of duplicating the same boilerplate in every file.

What makes Playwright assertions different from a simple equality check? Most Playwright assertions are web-first, meaning they retry automatically until a condition becomes true or a timeout is reached, rather than checking once and failing immediately. This is covered in depth in the Playwright assertions tutorial.

A soft assertion records a failure without stopping the test, letting it continue checking additional conditions in the same run. It is useful when verifying several related pieces of information on one page or flow.

When the same multi-line verification logic is repeated across many tests, a custom matcher built with expect.extend() keeps the suite cleaner than copying the same check everywhere.

Yes. Playwright includes a built-in request fixture that supports GET, POST, PUT, PATCH, and DELETE requests directly, covered with real examples in the Playwright API testing tutorial.

API calls can set up test data, like creating an account, far faster than clicking through a UI flow, letting a UI test focus only on the behavior it actually needs to verify.

The response headers and body as well, since a 200 status can still hide a missing field, wrong data type, or incorrect content type that a status check alone would miss.

Most commonly through GitHub Actions, installing dependencies, installing browser binaries with --with-deps, and running the suite on every push or pull request. A full working setup, including how AI and MCP fit into generating and troubleshooting that pipeline, is covered in the Playwright CI/CD setup guide.

It centralizes configuration for the entire suite, browsers to run against, timeouts, retries, reporters, and global setup, so behavior stays consistent across every machine and environment. This is covered in more depth in the test automation framework structure guide.

By grouping tests by feature or module, separating page objects, fixtures, utilities, and test data into their own folders, and using tagging to run targeted subsets like @smoke on demand rather than the full suite every time.

A fixture provides reusable setup scoped to individual tests that request it, while global setup runs once before the entire test run, typically used for one-time actions like preparing authentication state.

TypeScript catches a category of mistakes at compile time that JavaScript only surfaces at runtime, a typo in a property name, a function called with the wrong argument type, or a page object method used incorrectly. In a large test suite, this significantly reduces the kind of silent bugs that only show up when a test actually runs.

Each page object class gets typed constructor parameters and typed locator properties, typically Locator from @playwright/test. Interfaces can define the shape of data a page object’s methods accept, so a call like loginPage.login(credentials) is checked against a defined Credentials type rather than an untyped object.

Yes. test.extend<T>() accepts a type parameter describing each custom fixture, so autocomplete and type checking work correctly wherever that fixture is used, catching a fixture name typo or a misused property immediately rather than as a runtime failure deep into a test run.

No, the underlying API is identical. TypeScript only adds a type-checking layer on top, which is why teams already comfortable with the JavaScript patterns covered throughout this series can adopt TypeScript incrementally rather than needing to relearn Playwright itself.

AI assistants can generate a starting locator or page object from a page’s HTML, draft API tests directly from an OpenAPI specification, and suggest the most precise assertion for a given check, all of which speed up the mechanical work of authoring tests.
AI-Powered Test Automation with Playwright: Build a Complete AI Testing Framework

When a locator fails, a self-healing system compares the current page against a snapshot from the last successful run, looking for a similar element based on attributes, text, or role, and substitutes it if confidence is high enough. This speeds up recovery from minor UI changes but can occasionally mask a real regression, which is why review still matters.

It involves analyzing test results across many runs over time, not just one, to identify tests that fail intermittently for reasons unrelated to real bugs. A test failing once in fifty runs is easy to miss without this kind of historical analysis.

An approach that predicts which tests are relevant to a specific code change based on historical coverage data, running a prioritized subset instead of the entire suite on every commit, which becomes valuable once a suite grows large.

No. AI-generated tests, locators, and page objects are a strong starting point, but they still need a human review pass to confirm they test meaningful, real-world behavior rather than just whatever happens to pass today. This theme runs through the entire AI-Powered Test Automation with Playwright guide.

Start by checking for timing differences, a slower environment exposing a race condition, or an environment-specific value like a hardcoded local URL. The Trace Viewer and uploaded CI artifacts are usually the fastest way to see exactly what the runner saw.

Check what changed in the UI first, since a redesign or restructured component is the most common cause. Favor a role or text-based replacement over patching the same brittle CSS selector that broke in the first place.

If the goal is confirming backend correctness, an API test is faster and more reliable. If the goal is confirming the actual user-facing experience works, a UI test is necessary, and the two are often used together, API for setup, UI for the behavior that matters.

Yes. Junior interviews tend to focus on fundamentals, locators, and basic assertions. Senior interviews shift toward framework design, CI/CD strategy, and increasingly, how a candidate thinks about applying AI responsibly within a test suite.

Not necessarily, though many teams use TypeScript in production, so being comfortable reading typed examples is a practical advantage even if JavaScript is the primary language used day to day.

Increasingly important at companies actively adopting AI-assisted testing, though not yet universal. Being able to speak to both the benefits and the limits of AI in testing tends to stand out compared to candidates who have not thought about it at all.

Building a small real project using locators, a Page Object Model, API tests, and a CI/CD pipeline gives concrete examples to reference in an interview, which reads as far more credible than a memorized definition alone.

Yes, if used thoughtfully. Mentioning these tools alongside the caveat that AI-generated changes still need review shows both current awareness and sound judgment, which is a stronger answer than either ignoring AI entirely or treating it as a complete replacement for engineering judgment.