Playwright Questions Answered: A Practical Guide

This guide answers the most common practical questions about Microsoft Playwright, the open-source browser automation library. You’ll learn what Playwright is, how to install and run your first test, how to handle selectors and waits, and how to fix the frequent issues that trip up beginners and experienced users alike.

Formula

The calculator above estimates the total time needed to run a suite of Playwright tests. It uses the simple formula:

Total time (minutes) = Test duration (minutes) × Number of tests

Where:

• Test duration – the average time one test takes to run, in minutes.
• Number of tests – how many test cases are in your suite.

The second output converts the total into hours for easier scheduling. This is a planning tool only; actual runtime varies with machine speed, network latency, and parallel execution settings.

Worked Example

Using the defaults: 5 minutes per test and 10 tests.

1. Multiply: 5 × 10 = 50 minutes total.
2. Convert to hours: 50 ÷ 60 = 0.83 hours.

The calculator shows 50 minutes and 0.83 hours, matching the formula exactly.

What Playwright Actually Is

Playwright is a free, open-source framework released by Microsoft in 2020 for automating Chromium, Firefox, and WebKit browsers. Unlike Selenium, which drives browsers through a separate WebDriver server, Playwright talks to browsers directly via the DevTools Protocol. This gives it faster execution, more reliable waiting, and the ability to run tests in parallel across multiple browser engines with a single API.

It supports JavaScript/TypeScript, Python, Java, and .NET. The most common use is end-to-end testing of web applications, but it can also scrape data, take screenshots, generate PDFs, and monitor site performance.

How to Install and Write Your First Test

Installation is straightforward. For Node.js (the most popular setup), run:

npm init playwright@latest

This creates a test directory, installs the library, and downloads the browser binaries. For Python, use pip install playwright and then playwright install.

A minimal test in JavaScript looks like this:

const { test, expect } = require('@playwright/test');

test('homepage loads', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveTitle(/Example Domain/);
});

Run it with npx playwright test. The framework launches a browser, navigates to the URL, checks the title, and reports pass or fail with a detailed trace on failure.

Choosing Selectors: Best Practices

Playwright offers several ways to locate elements. The recommended priority is:

• Role-based selectors – getByRole('button', { name: 'Submit' }) – mimic how users and assistive tech find things.
• Label selectors – getByLabel('Email') – work for form fields.
• Text selectors – getByText('Welcome') – useful for non-interactive content.
• Test IDs – getByTestId('login-button') – stable if your team adds data-testid attributes.
• CSS/XPath – page.locator('.nav-item') – last resort because they break easily when markup changes.

Avoid brittle absolute paths like html > body > div > form > input. Prefer semantic selectors that describe the element’s purpose, not its position.

Handling Waits and Timeouts

One of Playwright’s biggest advantages over older tools is its auto-waiting. Actions like click() and fill() automatically wait for the element to be attached, visible, stable, and enabled. You rarely need explicit waitForTimeout() calls, which are discouraged because they slow tests and cause flakiness.

When you do need a custom wait, use:

• page.waitForSelector('.result') – waits for an element.
• page.waitForResponse(url) – waits for a network response.
• expect(locator).toHaveText('Done') – waits for a condition.

Set a global timeout in playwright.config.js with timeout: 30000 (30 seconds). If a test times out, the trace viewer shows the exact moment of failure, including network calls and DOM state.

Common Problems and Fixes

Beginners hit the same handful of issues. Here are the frequent ones and their solutions:

• Element not found – The selector is wrong or the element is inside an iframe. Use frameLocator() for iframes, and verify the selector in the Playwright Inspector.
• Strict mode violation – Your locator matches multiple elements. Narrow it with .first(), .nth(2), or a more specific role/name.
• Timeout while waiting for navigation – The page uses a client-side router. Use page.waitForURL() instead of waiting for load.
• Tests pass locally but fail in CI – Differences in screen resolution, browser version, or network speed. Use a fixed viewport and run with --headed locally to see what CI sees.
• Popup dialogs block execution – Handle them with page.on('dialog', dialog => dialog.accept()).

For debugging, use npx playwright test --debug to open the inspector, or --trace on to generate a trace file you can open in the trace viewer.

Playwright vs. Selenium vs. Cypress

Choosing a framework depends on your project. Here is a practical comparison:

• Playwright – Best for cross-browser testing, parallel execution, and modern web apps. Supports all three major engines out of the box. Slightly steeper learning curve than Cypress.
• Selenium – Mature, supports many languages and legacy browsers. Slower and more flaky due to WebDriver overhead. Still the choice for huge existing suites or when you must test Safari on real devices.
• Cypress – Great developer experience for front-end developers. Runs in the browser itself, but only supports Chromium and Firefox; no multi-tab or multi-domain testing without plugins.

If you need to test Safari/WebKit, Playwright is the only one of the three that does it natively. If you have a large Selenium suite, migrating gradually with Playwright’s @playwright/test runner is feasible because it can run alongside existing tests.

Costs and Limitations

Playwright itself is free and open-source under the Apache 2.0 license. The only costs are the infrastructure you run it on – CI minutes, cloud browsers, or local machines. There is no official cloud service, but you can use it with any CI provider like GitHub Actions, GitLab CI, or Jenkins.

Limitations to know:

• Mobile testing is emulated, not real-device. For true iOS Safari testing, you still need a real device or a cloud provider.
• Browser binaries are large (~300 MB each). Keep them cached in CI to avoid re-downloading.
• No built-in visual regression testing; you need a library like pixelmatch or a paid service.

Performance is generally excellent, but heavy tests with many screenshots or videos can slow down parallel runs. Use workers in the config to control parallelism.

Frequently Asked Questions

Do I need to install browsers separately? Yes, after installing the npm package, run npx playwright install to download Chromium, Firefox, and WebKit. You can install only one with npx playwright install chromium.

Can I use Playwright with an existing Selenium test? Not directly. The APIs are completely different. You would rewrite tests, but Playwright’s locator syntax is simpler, so the rewrite is often faster than maintaining flaky Selenium tests.

How do I test a login page with 2FA? You can’t automate the 2FA code itself. Instead, stub the authentication by setting a cookie or using a test user with 2FA disabled. Or use storageState to save the logged-in session after a manual login and reuse it.

Why is my test flaky on slow networks? The default timeout is 30 seconds. If your app loads slowly, increase the timeout in the config, but better, use expect(locator).toBeVisible() to wait for the specific element you need, not a blanket sleep.

Can I run tests in parallel? Yes, by default Playwright runs test files in parallel using worker processes. You can control the number with workers: 4 in the config. Each worker gets its own browser instance, so tests must be independent.

Is Playwright good for web scraping? Yes, it can handle JavaScript-heavy sites that plain HTTP requests can’t. Use page.goto(), wait for content, then extract with page.textContent() or page.$$eval(). Be mindful of the site’s terms of service and robots.txt.

Related

• Data Centers vs Cloud: Environmental Footprint
• Airtable Project Management Workflow: Step-by-Step
• Android Screen Recording Privacy: What Gets Captured

in t | Test duration | min | 5 | 0
in n | Number of tests | - | 10 | 1
out total | Total time | min | t * n | 0
out hours | Total hours | h | (t * n) / 60 | 2