Reporters & Test Artifacts

Q: Can I run more than one reporter at once?

Yes. The reporter option accepts an array, so a typical setup pairs a terminal reporter such as list or dot for live feedback with file reporters like html and junit for CI to ingest. Each reporter receives the same results independently.

Q: Which reporter should I use in CI?

Use a compact terminal reporter like dot to keep logs short, plus junit so the CI platform renders a native test view, and html with open set to never so a rich report is uploaded as a downloadable artifact. Reserve the verbose list reporter for local runs.

A test run produces two kinds of output: the human-readable verdict of what passed and what failed, and the forensic evidence — screenshots, video, and traces — you need to understand a failure you did not witness. Playwright ships several built-in reporters for the first and an artifact system for the second, and choosing the right combination for local development versus CI is what makes a red build actionable instead of a mystery. This guide, part of Debugging & Test Observability, covers every built-in reporter, the screenshot, video, and trace artifacts, and how to wire both into a continuous integration pipeline so every failure arrives with the evidence already attached.

One run fans out into human-readable reporters, machine-readable reporters for CI, and forensic artifacts; the CI dashboard consumes the machine output and links to the artifacts.

The built-in reporters

A reporter decides how results are printed and persisted. Playwright includes six, each suited to a different audience:

list — one line per test as it finishes, with status and duration. The clearest choice for local development because you see each result in context.
line — a single updating line showing progress and a running failure list. Compact for large suites where list would scroll endlessly.
dot — one character per test (a dot for pass, an F for fail). The most compact output, common in CI logs where space is at a premium.
html — a self-contained interactive report with per-test steps, attached artifacts, and a trace launcher. The richest format and the one to open after a failed CI run.
json — the full result tree as a JSON file, for custom dashboards or scripts that post-process results.
junit — an XML file in the JUnit schema that nearly every CI platform parses natively to render test tabs and failure annotations.

Configuring reporters

Set reporters in playwright.config.ts. You can run several at once — a terminal reporter for live feedback plus file reporters for CI to ingest — and switch the live one based on the CI environment variable:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  // Multiple reporters run together; each gets the same results.
  reporter: [
    // Compact dots in CI logs, readable list locally.
    [process.env.CI ? 'dot' : 'list'],
    // Interactive report; 'never' stops it auto-opening a browser in CI.
    ['html', { open: 'never', outputFolder: 'playwright-report' }],
    // Machine-readable output for the CI dashboard to parse.
    ['junit', { outputFile: 'results/junit.xml' }],
  ],
});

These reporter settings live beside the rest of your suite configuration documented in Playwright Config & Fixtures.

Artifacts: the forensic evidence

Reporters tell you a test failed; artifacts tell you why. Playwright can capture three kinds, all configured under use:

Screenshots — a single image, most useful captured only-on-failure.
Video — a recording of the whole test, valuable retain-on-failure to see the sequence that led to the break.
Trace — a complete, replayable record of every action, network call, and DOM snapshot, typically captured on-first-retry.

The practical recipe for wiring all three to failures, and attaching them to the HTML report, is covered step by step in Capturing Screenshots and Video on Test Failure.

Reading a trace

The trace is the richest artifact because it lets you replay a failure you never saw, scrubbing through the action timeline with before-and-after DOM snapshots and a full network panel. Opening and interpreting a trace is the subject of Trace Viewer & Debugging; capturing one is cheap with trace: 'on-first-retry', so a failed test on CI almost always leaves a trace you can pull down and open locally.

Wiring artifacts into CI

Artifacts only help if they survive the build. On CI, write reports and artifacts to a known folder and upload them as build artifacts so engineers can download them after the job ends. The JUnit XML feeds the platform's native test view, the HTML report becomes a downloadable bundle, and the trace files attach to the failures that produced them. The complete pipeline — caching browsers, sharding, and publishing these artifacts — is described in CI/CD Integration. The result is a failed build where every red test links directly to its screenshot, video, and trace.

Frequently Asked Questions

Can I run more than one reporter at once?

Yes. The reporter option accepts an array, so a typical setup pairs a terminal reporter such as list or dot for live feedback with file reporters like html and junit for CI to ingest. Each reporter receives the same results independently, so adding one never changes another's output.

Which reporter should I use in CI?

Use a compact terminal reporter like dot to keep logs short, plus junit so the CI platform renders a native test view, and html with open: 'never' so a rich report is uploaded as a downloadable artifact. Reserve the verbose list reporter for local runs where per-test context is more useful than brevity.

What is the difference between a screenshot and a trace?

A screenshot is a single image of the page at one moment, useful for a quick visual of the failure state, while a trace is a full replayable recording of every action, network request, and DOM snapshot across the whole test. A trace is far richer for diagnosis but larger, which is why it is usually captured only on the first retry.