Top 20 Playwright Interview Questions & Answers (2026 Edition)

Answer:

Playwright is a modern, open-source automation framework developed by Microsoft for end-to-end testing of web applications. It supports Chromium, Firefox, and WebKit browsers via a single API.

Key Differences from Selenium:

• Architecture: Selenium uses the WebDriver protocol (HTTP requests) to communicate with browsers, which can be slow and flaky. Playwright communicates directly with the browser using a WebSocket connection (Chrome DevTools Protocol), making it significantly faster and more reliable.
• Auto-waiting: Playwright automatically waits for elements to be actionable (visible, enabled, stable) before interacting with them. Selenium often requires explicit `WebDriverWait` statements.
• Browser Contexts: Playwright introduces isolated "Browser Contexts" that act like incognito windows, allowing parallel execution with zero cross-test interference in milliseconds.
• Network Interception: Playwright has built-in, native support for mocking and intercepting network requests without third-party tools.

Answer:

• Languages: TypeScript/JavaScript (primary/native), Python, Java, and C# (.NET).
• Browsers: Chromium (Chrome, Edge), Firefox, and WebKit (Safari engine). Playwright downloads these specific browser binaries natively ensuring complete cross-browser coverage.

Answer:

Auto-waiting is a core feature designed to eliminate test flakiness. Before Playwright performs an action (like `click()`, `fill()`, or `check()`), it automatically waits for a series of actionability checks to pass.

The element must be:

• Attached to the DOM
• Visible (not hidden by CSS)
• Stable (not animating or moving)
• Receives Events (unobscured by other elements like modals)
• Enabled (not disabled)

Interview Tip: Mention that because of auto-waiting, you almost never need to use page.waitForTimeout(5000) (hard sleeps) in Playwright, which is a common anti-pattern in Selenium.

Answer:

Playwright strongly recommends using user-facing locators (accessibility locators) because they mirror how users interact with the page, making tests highly resilient to DOM/CSS changes.

1. getByRole(): The absolute best locator. Finds elements by ARIA role, ARIA attributes, and accessible name (e.g., page.getByRole('button', { name: 'Submit' })).
2. getByText(): Finds non-interactive elements containing specific text.
3. getByLabel(): Essential for finding form inputs based on their associated `<label>`.
4. getByTestId(): When UI is complex, use data-testid attributes (highly resilient to refactors).

CSS and XPath selectors (page.locator('.btn-primary')) are considered the lowest priority and should only be used when necessary because they tie tests strictly to the DOM structure.

Answer:

If an element is hidden, Playwright's default auto-waiting for actions like `click()` will timeout because the element fails the "Visible" check. However, if you just want to assert its presence or text, you can do so.

If you must interact with a hidden element (e.g., triggering a hidden file input), you can bypass actionability checks using the force: true option:

await page.getByRole('button', { name: 'Hidden Actions' }).click({ force: true });

Alternatively, to write assertions regarding hidden elements, use: await expect(locator).toBeHidden().

Answer:

Shadow DOM: One of Playwright's greatest advantages is that its locators pierce Shadow DOM natively. Unlike Selenium, you don't need complex JavaScript executors; page.locator() and page.getByRole() just work inside Web Components automatically.

iFrames: You use the frameLocator() API to enter an iframe before locating elements within it.

const frame = page.frameLocator('#payment-frame');
await frame.getByRole('textbox', { name: 'Card Number' }).fill('4111');

Answer:

Playwright uses page.route() to intercept network traffic. This is extremely useful to test how the UI handles API errors or specific JSON payloads without touching the real backend.

await page.route('**/api/v1/users', async route => {
    // Fulfill the route with a mock JSON response
    const json = [{ id: 1, name: 'Alice (Mocked)' }];
    await route.fulfill({ json });
});

// The UI will now render the mocked user instead of hitting the real backend.

You can also use route.abort() to test how the UI handles network failures.

Answer:

When a button clicks opens a link in a new tab (target="_blank"), Playwright handles this via the context.waitForEvent('page') promise.

// Start waiting for new page before clicking
const pagePromise = context.waitForEvent('page');
await page.getByText('Open in new tab').click();

// Await the promise to get the new tab object
const newPage = await pagePromise;
await newPage.waitForLoadState();
await expect(newPage).toHaveTitle('New Document');

Answer:

Hard Assertions (expect()): If an assertion fails, the test immediately stops execution and throws an error. This is standard.

Soft Assertions (expect.soft()): If a soft assertion fails, the test logs the failure but continues to execute the rest of the test steps. Playwright will then mark the test as failed at the very end. This is useful when you want to check multiple independent UI elements (e.g., checking 5 different headers) without a single failure aborting the entire check.

Answer:

Playwright supports saving and reusing browser state (cookies, local storage, session storage). This is a game-changer for CI/CD speed.

1. You write a "Setup" script that logs in via UI or API.
2. You use page.context().storageState({ path: 'state.json' }) to save the authentication tokens.
3. In your playwright.config.ts, you configure your test projects to use this state.json via the use: { storageState: 'state.json' } property.

As a result, hundreds of parallel tests boot up already authenticated without ever executing the UI login flow.