How to test a web app before launch with Playwright

Release path

• Choose the journeys
• Control the environment
• Use user-facing locators
• Protect authentication state
• Capture failure evidence
• Add device coverage

1. Choose the five journeys that can stop a launch

A route inventory is not a test plan. Start with money and activation: what must a new user complete, what must a returning user recover, and which step hands off to an external provider?

Write the expected visible outcome before recording clicks. If the test cannot state what success looks like to the user, it cannot distinguish a real completion from a convincing screen.

2. Control the environment before interpreting a failure

3. Use the interface a user can perceive

Playwright recommends role, label, text, and explicit test-ID locators over CSS classes, DOM nesting, and XPath. Its locators auto-wait for actionability, and its web-first assertions retry until the expected state appears or the assertion times out.

await test.step('submit a valid signup', async () => {
  await page.getByLabel('Email').fill(testUser.email);
  await page.getByRole('button', { name: 'Create account' }).click();
  await expect(page.getByRole('heading', { name: 'Import your project' }))
    .toBeVisible();
});

• Name each test.step() as a user action or result.
• Assert the visible success state, URL, persisted record, or provider handoff—not merely that a click occurred.
• Avoid fixed sleeps. Wait on a user-visible state, response, URL, or stable locator.
• Do not test an external provider's entire UI. Verify the handoff you control and use its sandbox contract.

4. Reuse authentication without leaking it

Playwright can create an authenticated storage-state file in a setup project and reuse it across tests. That file can contain cookies and headers capable of impersonating the account, so the official documentation says to keep it in a gitignored playwright/.auth directory.

• Use disposable or staging-only accounts.
• Commit the setup code, never the generated state file.
• Use separate accounts when tests mutate shared server-side state in parallel.
• Delete or regenerate state when credentials expire or permissions change.
• Mask credentials and tokens in logs, screenshots, and traces before sharing artifacts.

5. Save the evidence that explains the first failure

A screenshot shows one frame. A useful failure record also preserves the step, URL, console, page exception, network clue, and trace. Playwright's trace viewer can show the action timeline, DOM snapshots, console, network, and source around a failed step.

Configure traces on the first retry or for focused debugging rather than recording every test indefinitely; Playwright notes that always-on tracing is performance-heavy.

6. Add device coverage after the core journey is stable

Playwright projects can emulate desktop browsers and mobile devices. Begin with the browser that matters most to the release, then add an iPhone-like and Android-like project for layout-sensitive flows. Check that navigation, fields, primary actions, error messages, and overflow remain visible and usable.

Device emulation does not reproduce every physical-device behavior. Treat it as repeatable viewport, input, and browser evidence; use real-device testing separately when hardware, camera, push, WebView, or platform-specific behavior matters.

Turn the plan into a browser evidence report

Common questions

Primary references

• Playwright: testing philosophy, locators, assertions, traces, and browsers
• Playwright: auto-retrying web assertions
• Playwright: authentication state and credential safety
• Playwright: trace viewer evidence
• Playwright: device and browser emulation
• Playwright: starting and waiting for a local web server