Playwright · Reliable end-to-end tests

What are the most important Playwright best practices?

Mediumbest practicestest designmaintainabilityUpdated Oct 2026
Quiz this track

Short answer

Test user-visible behaviour with role-based locators, rely on auto-waiting and web-first assertions, isolate each test, and keep fixtures and page objects thin. Capture traces on failure.

Good Playwright tests are short, deterministic and written in the language of the user. Most maintenance problems come from brittle selectors, manual sleeps, shared data and tests that assert implementation details instead of outcomes.

The practices that matter most

  • Prefer role, label and text locators over CSS paths and test IDs
  • Never use fixed sleeps; use web-first assertions and auto-waiting
  • Keep tests independent with fresh contexts and unique data
  • Assert on user-visible outcomes, not internal state or hook calls
  • Use fixtures for setup and teardown instead of repeated beforeEach blocks
  • Keep page objects thin and leave assertions in the test
  • Record a trace on first retry and review failures instead of retrying blindly
  • Run the fast suite on every commit and the full browser matrix on a schedule
ts
test("filters active invoices", async ({ page }) => {
  await page.goto("/invoices");

  await page.getByRole("button", { name: "Active" }).click();

  await expect(page.getByRole("row")).toHaveCount(3);
  await expect(page.getByRole("row").first()).toContainText("Active");
});
A good test reads as a user action followed by a user-visible expectation, with no sleeps or selectors.

Structure matters as the suite grows. Group tests by feature, share domain-specific fixtures, and keep one clear reason to fail per test. A test that checks five unrelated things produces a vague failure and slows down diagnosis.

Do not chase a green pipeline by adding retries, longer timeouts or serial mode. Those are containment tools. The durable fix is deterministic data, condition-based waiting and tests that verify behaviour rather than implementation.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Why are role locators better than CSS selectors?
  2. 2When should you use a page object?
  3. 3How do you keep tests independent?
  4. 4What is the problem with adding retries to a flaky suite?

Say it in the interview

I keep tests focused on user-visible behaviour, use role and label locators, and rely on auto-waiting instead of sleeps. Each test gets isolated state and unique data, and fixtures handle setup and cleanup. I keep page objects thin and leave assertions in the test. When something fails, I look at the trace and fix the cause rather than adding retries or serial mode.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Playwright mock interview and get scored feedback on depth, clarity and confidence.