Generating and viewing test reports

The Default HTML Reporter

The HTML reporter is the primary visual interface for analyzing test results. When you execute your test suite, Playwright automatically generates a standalone web application containing a complete breakdown of every test file, individual test cases, and the underlying steps taken during execution. This report works because Playwright captures the entire execution lifecycle as an event stream, which the reporter then processes into a structured view. By default, this creates a 'playwright-report' directory in your project root. The power of this approach lies in the ability to drill down into specific failures, seeing exactly which selector failed or which assertion did not meet expectations. It is effectively a snapshot of your browser interactions mapped against your expectations. Because the report is a static set of files, you can easily host it on any static web server to share results across your entire engineering team, facilitating faster troubleshooting during the development cycle.

// To generate, run: npx playwright test
// By default, it creates an HTML report.
// You can open it manually using this command:
npx playwright show-report

Configuring Reporters in playwright.config

The 'playwright.config' file serves as the brain of your testing framework, dictating how test outcomes are formatted and stored. You define your reporting strategy inside the 'reporter' array. Why does this design matter? Because it allows for multiple output formats simultaneously—you can generate a human-readable HTML report for local inspection while simultaneously outputting a machine-readable JSON or JUnit XML file for your continuous integration pipeline to parse. The configuration is evaluated before any tests begin, ensuring that the necessary listeners are registered to track every 'test.step' and assertion. If you find the default behavior lacking, you can extend this array with custom reporters or community-provided plugins. By centralizing reporting logic here, you decouple the execution logic of your tests from the output format, meaning you can change your entire reporting infrastructure without ever touching your actual test source code files.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  // Define multiple reporters to track progress and output results
  reporter: [['list'], ['html', { open: 'never' }], ['junit', { outputFile: 'results.xml' }]],
});

Debugging with Trace Viewer

While standard reports tell you what failed, the Trace Viewer shows you exactly how the browser state evolved leading up to that failure. It acts as a time-travel debugger for your automation. When you enable tracing, Playwright records a detailed log of every network request, console log, snapshot of the DOM, and action performed on elements. This is infinitely more powerful than static screenshots because it allows you to inspect the page state at any point in the test execution. When a test fails, you can open the specific trace file in the viewer to inspect individual network requests and view the state of your application components just milliseconds before an assertion failed. This mechanism works by serializing the browser's internal state into a 'trace.zip' file. Since the viewer allows you to play back the execution, it removes the common 'it works on my machine' headache, providing an objective record of events for every stakeholder involved in the debugging process.

// playwright.config.ts
export default defineConfig({
  use: {
    // Record traces for every test to enable post-mortem analysis
    trace: 'on-first-retry',
  },
});
// View the trace:
npx playwright show-trace trace.zip

Attaching Artifacts to Reports

In complex testing scenarios, standard logs are often insufficient to explain why a test failed. Playwright allows you to programmatically attach arbitrary artifacts—such as screenshots, videos, or custom log data—directly to the test reporter using the 'testInfo' object. This works by associating metadata with the test execution context during runtime. When a test enters a failing state, you can capture the current viewport screenshot and attach it to the report object. Because these attachments are persisted within the test execution lifecycle, the HTML reporter automatically incorporates them into the final dashboard. This level of customization is crucial for complex applications where an error might be hidden in a specific network request or an unhandled console error. By programmatically injecting evidence into your report, you transform the test outcome from a simple 'Pass/Fail' indicator into a comprehensive diagnostic document that tells a complete story about the system's behavior.

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

test('capture logs on failure', async ({ page }, testInfo) => {
  await page.goto('https://example.com');
  // Attach a custom screenshot if the test fails
  const screenshot = await page.screenshot();
  await testInfo.attach('failure-screenshot', { body: screenshot, contentType: 'image/png' });
});

CI Integration and Streamed Reporting

Integrating test reports into a CI/CD pipeline requires a streaming reporter that provides immediate feedback to engineers. The 'dot' or 'list' reporters are specifically designed to output results to the standard output buffer as tests complete, rather than waiting for the entire suite to finish. This is vital for CI efficiency; if a suite takes thirty minutes, you want to know if a regression occurs in the first minute. By using these reporters, your CI system can capture logs and display them in real-time. Furthermore, when the suite finishes, the CI system can collect the generated HTML and Trace artifacts, archiving them as build artifacts. This creates a feedback loop where engineers are notified of failures via their build tool and can download the associated trace files to investigate remotely. This end-to-end integration ensures that visibility remains high, even when tests are running on headless virtual machines in a remote cloud environment.

// Run in CI with high-verbosity for better log tracking
// The 'list' reporter is ideal for console visibility
npx playwright test --reporter=list

// Generate a JUnit report specifically for CI parsing
npx playwright test --reporter=junit

Interview questions

All Playwright interview questions →

Check yourself

Take the full Playwright quiz →