Playwright evidence: turn test output into a reviewable release

Playwright runs assertions and compares visual snapshots. It can produce reports and traces when configured. If your team runs Playwright today, you may already have useful evidence artifacts. This guide covers what happens to that evidence after the run finishes. Playwright's own docs are worth reading directly for the assertion side; this guide is about the review side.

Match the artifact to the question

A screenshot answers what the page looked like at capture time. A screenshot comparison checks a rendered image against a baseline under declared conditions. An assertion evaluates one specific expectation. A trace helps investigate what happened during a recorded test run. Playwright documents these as distinct capabilities, and they aren't interchangeable: a successful screenshot command isn't a successful business transaction, a passing text assertion isn't a comprehensive visual review, and a baseline image is an approved reference, not an independent definition of correctness. Keep failed, skipped, and blocked tests in the packet — leaving them out makes a run look more complete than it was.

An explicit assertion tied to a named capture

This minimal, illustrative and unexecuted example exercises a local synthetic HTML fixture. It makes no external request and uses no production credentials — it illustrates the relationship between a test, a state, and a screenshot, not a real invitation flow, and it was not run as part of preparing this guide.

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

test.use({ viewport: { width: 390, height: 844 } });

test('synthetic invitation action is visible in the viewport', async ({ page }, testInfo) => {
  await page.setContent(`
    <main>
      <h1>Invite a teammate</h1>
      <p>Synthetic fixture. No email will be sent.</p>
      <button type="button">Send invitation</button>
    </main>
  `);

  const action = page.getByRole('button', { name: 'Send invitation' });
  const screenshotPath = testInfo.outputPath('invitation-ready-mobile.png');

  try {
    await expect(action).toBeVisible();
    await expect(action).toBeInViewport({ ratio: 1 });
  } finally {
    // Capture the state after the assertion attempt, including a failure.
    await page.screenshot({ path: screenshotPath, fullPage: true });
  }
});

Run it in your own Playwright Test project with its installed version and config before relying on it — a maintainer should verify it, not assume it from reading this page. The assertions here only cover visibility and viewport intersection; they don't prove that clicking the button sends an invitation, that the recipient receives email, or that the backend enforces authorization.

What a useful evidence record includes

Beyond the pass/fail, a record worth reviewing later names: the release, the reported source commit, a run identifier, the route or fixture identity, the state and role under test, the viewport, browser version, capture time, each assertion's name and outcome, and a reference to the artifact itself — plus whether the fixtures or network responses were synthetic. Keep stable logical screen names (invitation / ready / administrator) so a build number changing doesn't break comparability, and keep the environment reproducible — Playwright's own docs note that screenshot output can vary across operating systems, browsers, and fonts.

Traces are for investigation, not decoration

A trace can carry action details and recorded page state that make a failed step far easier to understand than a polished screenshot alone. Choose what to collect based on the problem and your storage budget: keep the detailed technical artifact available to whoever debugs it, and hand the reviewer a smaller, relevant packet. A Playwright report is a useful presentation of run results — it isn't automatically a client-ready release history on its own.

Protect authentication and fixture data

Playwright warns that saved authentication state can contain sensitive information that could be used to impersonate an account — keep it out of repositories and out of any evidence packet you share. Review screenshots, traces, request details, and labels before sharing; removing a token from a screenshot doesn't remove it from an attached trace or log. Prefer scoped synthetic accounts and deliberately seeded fixtures over real credentials.

Two separate things UIProof brings in, kept separate

• Captured screenshots can be uploaded directly from a browser (PNG/JPG/WebP, up to 12 files per release, 3 MB each), or imported in bulk from an extracted Site Atlas report with the CLI importer (up to 100 screens per release). The importer isn't a general-purpose Playwright HTML-report or ZIP parser — it reads a specific extracted-report format, only uploads to the configured origin, and never auto-publishes.
• Reported check results — your own passed/failed/skipped/blocked verdicts, each marked required or not — can be attached to a release as data alongside the screenshots. These are labeled reported, deliberately: UIProof didn't execute or re-verify them, and a required check that was skipped or blocked stays counted against the release instead of quietly disappearing from the score.

Neither path means UIProof runs your Playwright suite for you. If your pipeline produces something the importer doesn't read today, the honest starting point is the browser uploader, not an assumed integration. Keep the original test outcome and its source distinct from the review observation — a developer's reported pass stays a reported pass, and a reviewer's note stays a review note.

A separately executed synthetic example

The mobile-invitation-clipped review pattern is a small, executed synthetic illustration of the same idea behind Playwright-style geometry assertions: a synthetic fixture, a headless browser, and a scripted DOM check (getBoundingClientRect plus computed overflow) — not an eyeballed screenshot. Unlike the code sample above, that pattern page's fixture actually was run once, locally, to produce its before/after evidence and receipt; it's a separate, already-executed example, not a claim that UIProof executed the snippet on this page.

Put it together

Start from the release-review checklist if you want the practical steps, or create a private board and bring in your next report.

Sources and limitations

Playwright: Visual comparisons, Assertions, Trace viewer, Reporters, and Authentication. See also product status. This guide neither benchmarks Playwright against UIProof nor claims comprehensive application coverage; the code sample above is illustrative and unexecuted.