What Is Playwright? Browser Testing Explained With an Example

Key takeaways

• Playwright automates browsers, while Playwright Test adds a JavaScript and TypeScript test runner and supporting tools.
• Locators and retrying assertions help tests follow observable interface state.
• Browser-context isolation does not isolate a shared database or backend automatically.
• Mocks, screenshots, and traces provide different evidence and should match the purpose of the test.

Playwright is an open-source browser automation project from Microsoft. It can drive Chromium, Firefox, and WebKit to exercise web pages through actions such as navigation, typing, and clicking.

For JavaScript and TypeScript, Playwright Test combines browser automation with a test runner, assertions, fixtures, and reporting. The official introduction provides installation and setup guidance.

Suppose a customer changes their delivery address. A useful browser test fills the form, submits it, and checks the visible confirmation. It can also reload the page to establish that the saved address persists.

That last step matters: showing a success message and saving the data are different behaviors.

A Small Playwright Test

This example assumes a running test application at the stated local URL, an account that can open the address page, and a field labeled “Street address.” The application exposes save feedback through a status region.

import { test, expect } from '@playwright/test';

test('persists a delivery address', async ({ page }) => {
  await page.goto('http://localhost:3000/account/address');

  const address = page.getByLabel('Street address');
  await address.fill('42 Example Lane');

  await page.getByRole('button', { name: 'Save address' }).click();
  await expect(page.getByRole('status')).toHaveText('Address saved');

  await page.reload();
  await expect(address).toHaveValue('42 Example Lane');
});

The route and labels are illustrative application details. A real suite needs deliberate authentication and test-data setup.

The assertions describe observable outcomes. The test does not consider a successful click sufficient evidence that the address was saved.

Locators Describe the Interface

A locator describes how to find an element and resolves it when needed. Role and label locators connect tests to the semantics people use to understand the interface.

Playwright’s locator guide recommends user-facing attributes and explicit contracts such as test IDs.

A locator like “button named Save address” usually survives a harmless wrapper change better than a long CSS path. If several buttons match, narrow the locator to the relevant form or region rather than selecting the first match without explanation.

Good locators improve clarity, but using role-based queries does not by itself establish that the whole page is accessible.

Auto-Waiting Handles Action Readiness

Before actions such as clicking, Playwright checks conditions including visibility, stability, event reception, and whether the target is enabled. Its auto-waiting documentation explains the checks for different actions.

Retrying assertions wait for their expected state within a timeout. That lets the address test wait for the confirmation instead of sleeping for an arbitrary number of seconds.

Auto-waiting does not know every business condition. A background export can continue after a button becomes clickable. The test must assert the completion state that matters.

Increasing timeouts should follow evidence that legitimate work needs more time, rather than concealing a missing readiness signal.

Isolate Browser State and Application Data

Playwright Test uses isolated browser contexts by default. These separate browser state such as cookies and local storage; the isolation guide explains the model.

A context does not create a separate backend database.

If two parallel address tests modify the same customer account, they can still interfere. Use independent records or accounts where the test changes server-side state, and clean up according to the test environment’s lifecycle.

This distinction becomes important when a test passes alone and fails only in a full suite.

Use Network Mocks for a Specific Purpose

Network interception can supply controlled responses. Playwright’s API mocking guide shows how to intercept and fulfill requests.

For the address form, a mocked failure can exercise an error message without making the real service unavailable. That is useful coverage of frontend behavior.

It does not verify that the real address service accepts the request or persists the data. Keep a separate integration path for those claims.

The test name and assertions should make the scope clear: “shows an error when saving fails” promises different evidence from “persists an address.”

Browser Coverage and Failure Diagnosis

Browser projects let a suite run under different configurations. Choose coverage around supported environments and behavior likely to vary. Mobile emulation approximates selected device properties; it does not replace all testing on real devices.

When a test fails, Trace Viewer can help inspect actions, page snapshots, and network activity. That evidence is often more useful than rerunning until the failure disappears.

Retries can distinguish intermittent behavior from consistent failures, but a retry passing does not explain the original failure. Investigate recurring instability instead of treating retries as a repair.

Where Screenshots Fit

A functional address test can pass while a CSS change clips the field label. Visual regression testing adds a comparison of rendered appearance.

Use that evidence alongside functional assertions. A screenshot cannot establish that the backend saved the address, while a persistence assertion does not establish that the layout remains usable.

Playwright is most valuable where the browser contributes necessary evidence: rendered controls, navigation, form interaction, and frontend integration. Pure calculations and isolated business rules can usually be tested more directly without launching a browser.

A browser test is useful when its assertions describe the behavior a user actually needs.