Introduction: Why Playwright Reporting Matters in 2026
A successful automation framework should do more than execute tests. It should clearly communicate what passed, what failed, why a test failed, how long execution took, and what evidence is available for debugging.
This is where Playwright reporting becomes important.
Microsoft Playwright includes several built-in reporters, including HTML, JSON, JUnit, List, Line, Dot, GitHub, and others. The HTML reporter provides an interactive report where testers can inspect test results, errors, steps, and attachments.
For QA Automation Engineers and SDETs, reporting is especially valuable when tests run:
- Locally during development
- Across Chromium, Firefox, and WebKit
- In parallel
- Inside Docker
- Through GitHub Actions
- Through Jenkins
- Through Azure DevOps
- As part of a CI/CD pipeline
This playwright reporting tutorial explains how to build a practical reporting solution from beginner level to an enterprise-style automation framework.
What Is Playwright Reporting?
Playwright reporting is the process of collecting and presenting Playwright test execution results in a readable format.
A Playwright test report can contain information such as:
- Passed tests
- Failed tests
- Skipped tests
- Flaky tests
- Execution duration
- Error messages
- Test steps
- Screenshots
- Videos
- Trace files
- Browser information
- Test artifacts
The Playwright Test runner supports built-in reporters and also allows teams to create custom reporters.
Why is reporting necessary?
Imagine running 500 automated tests in a CI pipeline.
A terminal message saying:
47 failed
453 passed
does not provide enough information.
A useful report should help answer:
Which tests failed?
Which browser failed?
What assertion failed?
What was the URL?
Is there a screenshot?
Is there a trace?
Can another engineer reproduce the failure?
That is the purpose of Playwright report generation.
Why Use Playwright Test Reports?
A professional Playwright Testing Framework should combine automation + reporting + debugging + CI/CD.
The major benefits are:
| Benefit | Explanation |
| Faster debugging | Failures can include screenshots, videos, and traces |
| Better visibility | Teams can quickly see pass/fail results |
| CI/CD integration | JSON/JUnit results can be consumed by CI tools |
| Historical analysis | Reports can be retained as build artifacts |
| Parallel execution | Large suites can execute concurrently |
| Team communication | HTML reports are easier to share |
| Interview value | Demonstrates framework-level automation knowledge |
For a QA engineer, reporting knowledge shows that you understand the complete automation lifecycle rather than only writing test scripts.
Playwright Built-in Reporters Overview
Playwright provides several built-in reporters.
| Reporter | Best Use |
| HTML | Human-readable interactive reports |
| List | Local development |
| Line | Compact local output |
| Dot | Very compact CI output |
| JSON | Dashboards and automation |
| JUnit | Jenkins and CI test-result systems |
| GitHub | GitHub Actions annotations |
| Custom | Organization-specific requirements |
Playwright’s configuration supports reporters as strings or reporter-plus-options tuples.
Setting Up a Playwright Project for Reporting
If you are starting from scratch, create a Playwright TypeScript project:
npm init playwright@latest
Choose:
TypeScript
tests
The Playwright project scaffold includes playwright.config.ts, a test directory, and package configuration.
Run your tests:
npx playwright test
Configuring the Playwright HTML Reporter
The HTML reporter is usually the best starting point for beginners.
Create or update playwright.config.ts:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
reporter: [
[‘html’, {
outputFolder: ‘playwright-report’,
open: ‘never’
}],
[‘list’]
],
use: {
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’,
trace: ‘retain-on-failure’
}
});
This is a practical playwright reporting tutorial example because it combines the HTML report with debugging artifacts.
What does each option do?
html
[‘html’, { outputFolder: ‘playwright-report’ }]
Generates the interactive HTML report.
The default output directory is playwright-report, but you can configure another directory.
open: ‘never’
open: ‘never’
Prevents Playwright from automatically opening the report after execution.
This is useful in CI/CD environments.
Other supported values include:
always
never
on-failure
The default behavior is on-failure.
screenshot: ‘only-on-failure’
Captures screenshots when tests fail.
video: ‘retain-on-failure’
Records test execution and retains videos for failed tests.
trace: ‘retain-on-failure’
Collects Playwright traces when tests fail.
This gives developers multiple layers of debugging evidence.
Running Tests and Generating an HTML Report
Run:
npx playwright test
After execution, Playwright creates:
playwright-report/
Open the report:
npx playwright show-report
You can also specify a custom report directory:
npx playwright show-report playwright-report
Playwright serves the report locally instead of requiring you to open the HTML file directly.
Opening and Understanding the Playwright HTML Report
The Playwright HTML Report provides an interactive view of the test run.
Depending on the execution, you can inspect:
- Passed tests
- Failed tests
- Skipped tests
- Flaky tests
- Browser/project
- Test duration
- Error messages
- Test steps
- Attachments
- Screenshots
- Videos
- Traces
The report also supports filtering and searching, making it easier to investigate large test suites.
For example, a failed checkout test might show:
E-Commerce Checkout
✘ should reject expired card
Error:
Expected “Payment successful”
Received “Card expired”
The engineer can then inspect the associated screenshot or trace.
List, Line, Dot, JSON, and JUnit Reporters
List Reporter
reporter: ‘list’
Best for local development.
It displays individual tests with readable output.
Line Reporter
reporter: ‘line’
Provides compact output while still showing useful execution information.
Dot Reporter
reporter: ‘dot’
Produces highly compact output and is useful when terminal output should remain small.
JSON Reporter
reporter: [[‘json’, {
outputFile: ‘test-results/results.json’
}]]
JSON is useful when another application needs to consume test results.
Examples include:
- Internal dashboards
- Metrics systems
- Test management integrations
- Custom scripts
JUnit Reporter
reporter: [[‘junit’, {
outputFile: ‘test-results/results.xml’
}]]
JUnit XML is particularly useful for CI systems and test-result publishing.
Configuring Multiple Playwright Reporters
A real project can use several reporters simultaneously:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
reporter: [
[‘html’, {
outputFolder: ‘playwright-report’,
open: ‘never’
}],
[‘json’, {
outputFile: ‘test-results/results.json’
}],
[‘junit’, {
outputFile: ‘test-results/results.xml’
}],
[‘list’]
],
use: {
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’,
trace: ‘retain-on-failure’
}
});
A common strategy is:
HTML → QA engineers
JSON → dashboards/automation
JUnit → CI systems
List → local developers
Custom → organization-specific systems
This is often better than trying to make one reporter satisfy every requirement.
Screenshots, Videos, and Trace Viewer in Reports
Reporting becomes much more powerful when test artifacts are included.
Screenshots
use: {
screenshot: ‘only-on-failure’
}
A screenshot provides visual evidence of the browser state when the failure occurred.
Videos
use: {
video: ‘retain-on-failure’
}
Video can help explain failures involving:
- Navigation
- Popups
- Dynamic elements
- Unexpected redirects
- UI timing
Trace Viewer
use: {
trace: ‘retain-on-failure’
}
A Playwright trace can provide detailed execution information.
You can open an individual trace with:
npx playwright show-trace trace.zip
Playwright also provides trace-related debugging capabilities through its tooling.
For CI failures, traces are especially useful because the engineer may not have access to the original browser session.
Capturing Test Failures and Debugging Information
A useful debugging configuration is:
use: {
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’,
trace: ‘retain-on-failure’
}
You can additionally use Playwright’s debugging features locally:
npx playwright test –debug
The Playwright Inspector can help you investigate locators, steps, and browser behavior.
A practical debugging process is:
- Open the HTML report.
- Locate the failed test.
- Read the assertion error.
- Inspect the screenshot.
- Watch the video if available.
- Open the trace.
- Identify the failed action.
- Reproduce the problem locally.
- Fix the test or application issue.
- Re-run the test.
Playwright Reporting with Page Object Model and Fixtures
Reporting should not make your Page Object Model complicated.
Example:
import { Page, Locator } from ‘@playwright/test’;
export class LoginPage {
readonly page: Page;
readonly username: Locator;
readonly password: Locator;
readonly loginButton: Locator;
constructor(page: Page) {
this.page = page;
this.username = page.getByLabel(‘Username’);
this.password = page.getByLabel(‘Password’);
this.loginButton = page.getByRole(‘button’, {
name: ‘Login’
});
}
async login(username: string, password: string) {
await this.username.fill(username);
await this.password.fill(password);
await this.loginButton.click();
}
}
Test:
import { test, expect } from ‘@playwright/test’;
import { LoginPage } from ‘../pages/LoginPage’;
test(‘valid login’, async ({ page }) => {
const loginPage = new LoginPage(page);
await page.goto(‘/login’);
await loginPage.login(‘testuser’, ‘password’);
await expect(page).toHaveURL(/dashboard/);
});
The reporter records the test result while the Page Object Model keeps application interaction code maintainable.
Playwright Reporting for Parallel Test Execution
Playwright can execute tests in parallel.
For example:
export default defineConfig({
fullyParallel: true,
reporter: [
[‘html’, { open: ‘never’ }],
[‘list’]
]
});
Parallel execution reduces total execution time, but reporting becomes more important because failures can happen simultaneously.
For large CI suites, Playwright also supports sharding. Sharded runs can produce blob reports that are later merged into a single HTML report.
Example:
npx playwright test –shard=1/4
After collecting the reports:
npx playwright merge-reports –reporter html ./all-blob-reports
This is valuable for enterprise automation suites with hundreds or thousands of tests.
Playwright Reporting in CI/CD Pipelines
A professional Playwright CI/CD implementation should preserve reports after the pipeline finishes.
A typical workflow is:
↓
CI pipeline starts
↓
Install dependencies
↓
Install browsers
↓
↓
Generate HTML/JSON/JUnit reports
↓
Upload reports
↓
Engineer investigates failures
Playwright’s official CI guidance demonstrates uploading the playwright-report directory as a GitHub Actions artifact.
Playwright Reporting with GitHub Actions
Example:
name: Playwright Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v6
– uses: actions/setup-node@v6
with:
node-version: lts/*
– name: Install dependencies
run: npm ci
– name: Install Playwright
run: npx playwright install –with-deps
– name: Run Playwright tests
run: npx playwright test
– name: Upload Playwright report
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v5
with:
name: playwright-report
path: playwright-report/
retention-days: 30
This preserves the report even when tests fail.
The official Playwright CI documentation uses the same general artifact-upload approach.
Playwright Reporting with Jenkins
For Jenkins, JUnit is useful:
reporter: [
[‘html’, {
outputFolder: ‘playwright-report’,
open: ‘never’
}],
[‘junit’, {
outputFile: ‘test-results/results.xml’
}]
]
Your Jenkins pipeline can execute:
npm ci
npx playwright install –with-deps
npx playwright test
Then publish:
test-results/results.xml
as JUnit test results and archive:
playwright-report/**
test-results/**
This gives Jenkins structured test results while retaining the detailed Playwright HTML report.
Playwright Reporting with Azure DevOps
Azure Pipelines can publish JUnit results and preserve the HTML report as a pipeline artifact.
Example:
– script: npm ci
displayName: Install dependencies
– script: npx playwright install –with-deps
displayName: Install Playwright
– script: npx playwright test
displayName: Run Playwright tests
env:
CI: ‘true’
– task: PublishTestResults@2
condition: succeededOrFailed()
inputs:
searchFolder: ‘test-results’
testResultsFormat: ‘JUnit’
testResultsFiles: ‘results.xml’
mergeTestResults: true
– task: PublishPipelineArtifact@1
condition: succeededOrFailed()
inputs:
targetPath: ‘playwright-report’
artifact: ‘playwright-report’
publishLocation: ‘pipeline’
Playwright’s CI documentation specifically documents JUnit publishing and Azure Pipeline artifact handling.
Docker-Based Playwright Reporting
Docker is useful when you want consistent test environments.
A typical flow is:
docker build -t playwright-tests .
docker run –rm \
-v “$(pwd)/playwright-report:/app/playwright-report” \
playwright-tests
The important concept is to persist the report directory outside the container.
Otherwise, the container may be removed and the report can disappear with it.
Playwright Custom Reporter Example
Sometimes an organization needs a custom format.
Playwright allows a custom reporter to implement reporter lifecycle methods.
Create:
reporters/custom-reporter.ts
import type {
Reporter,
FullConfig,
Suite,
TestCase,
TestResult
} from ‘@playwright/test/reporter’;
class CustomReporter implements Reporter {
onBegin(config: FullConfig, suite: Suite) {
console.log(
`Starting ${suite.allTests().length} tests`
);
}
onTestBegin(test: TestCase) {
console.log(`STARTED: ${test.title}`);
}
onTestEnd(test: TestCase, result: TestResult) {
console.log(
`FINISHED: ${test.title} – ${result.status}`
);
}
onEnd() {
console.log(‘Test execution completed.’);
}
}
export default CustomReporter;
Configure it:
reporter: [
[‘html’, { open: ‘never’ }],
[‘./reporters/custom-reporter.ts’]
]
Custom reporters can be useful for:
- Internal dashboards
- Slack notifications
- Test management systems
- Organization-specific metrics
- Custom pass/fail summaries
Real-World E-Commerce Playwright Reporting Project
A strong portfolio project can be structured like this:
ecommerce-playwright/
│
├── tests/
│ ├── login.spec.ts
│ ├── search.spec.ts
│ ├── filter.spec.ts
│ ├── cart.spec.ts
│ └── checkout.spec.ts
│
├── pages/
│ ├── LoginPage.ts
│ ├── ProductPage.ts
│ ├── CartPage.ts
│ └── CheckoutPage.ts
│
├── fixtures/
│ └── test-fixtures.ts
│
├── reporters/
│ └── custom-reporter.ts
│
├── test-results/
├── playwright-report/
├── playwright.config.ts
└── package.json
Recommended test scenarios
Login
- Valid credentials
- Invalid password
- Empty username
- Empty password
Product search
- Search existing product
- Search nonexistent product
- Case-sensitive search validation
Product filtering
- Price filter
- Category filter
- Brand filter
Cart
- Add product
- Remove product
- Update quantity
- Verify cart total
Checkout
- Valid checkout
- Missing address
- Invalid payment information
- Expired card
Configure:
use: {
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’,
trace: ‘retain-on-failure’
}
Then run:
npx playwright test
npx playwright show-report
This project demonstrates much more than basic UI automation.
It demonstrates:
Automation + Page Object Model + Fixtures + Reporting + Parallel Execution + Debugging + CI/CD.
That combination is valuable for QA Automation and SDET portfolios.
Common Playwright Reporting Errors and Solutions
1. HTML report is missing
Check:
playwright.config.ts
and confirm:
reporter: [[‘html’, { open: ‘never’ }]]
Then execute:
npx playwright test
2. show-report cannot find the report
Check whether:
playwright-report/
actually exists.
For a custom folder:
npx playwright show-report my-report
3. Screenshots are missing
Make sure:
screenshot: ‘only-on-failure’
is configured and the test actually fails.
4. Trace is missing
Verify:
trace: ‘retain-on-failure’
Also inspect the test-results directory.
5. CI artifact is missing
Use:
if: ${{ !cancelled() }}
for the upload step so artifacts can still be uploaded after test failures. Playwright’s GitHub Actions examples use this pattern.
6. CI report cannot be opened directly
The HTML report should be served through Playwright:
npx playwright show-report
rather than simply double-clicking index.html. Playwright’s documentation recommends using the report server for downloaded CI reports.
Playwright Reporting Best Practices
Follow these practices when designing a production reporting solution:
- Use HTML reports for human investigation.
- Use JUnit for CI test-result publishing.
- Use JSON when another application needs structured results.
- Capture screenshots primarily on failure.
- Retain videos on failure instead of every test when storage matters.
- Collect traces on failure for difficult debugging.
- Keep reports as CI artifacts.
- Use meaningful test and describe names.
- Use Page Object Model for maintainability.
- Use fixtures for reusable setup.
- Use parallel execution carefully.
- Use sharding for very large suites.
- Merge sharded reports when necessary.
- Avoid storing secrets in screenshots or traces.
- Control artifact retention periods.
- Review report storage costs for large suites.
Playwright’s CI guidance also warns that reports, traces, and logs can contain credentials, access tokens, source code, or other sensitive information, so they should be stored and shared securely.
Third-party solutions such as Allure Report and other specialized reporting platforms can also be considered when teams need additional dashboards, historical analytics, or integrations beyond the built-in Playwright reporters.
Playwright Reporting Interview Questions With Answers
1. What is Playwright reporting?
Playwright reporting is the process of collecting and presenting automated test execution results using reporters such as HTML, JSON, JUnit, List, and custom reporters.
2. What is the default Playwright HTML report location?
The standard HTML reporter output directory is:
playwright-report
It can be customized through reporter configuration.
3. How do you open a Playwright HTML report?
npx playwright show-report
4. How do you capture screenshots only for failed tests?
use: {
screenshot: ‘only-on-failure’
}
5. How do you generate a JUnit report?
reporter: [
[‘junit’, {
outputFile: ‘test-results/results.xml’
}]
]
6. Why use multiple reporters?
Different consumers need different formats.
For example:
HTML → humans
JSON → dashboards
JUnit → CI
List → developers
Custom → internal systems
7. How do you preserve Playwright reports in CI?
Upload:
playwright-report/
as a CI artifact.
8. What is a Playwright trace?
A trace is a detailed execution artifact that helps engineers understand what happened during a test and debug failures.
9. Can Playwright create custom reporters?
Yes. A custom reporter can implement Playwright’s reporter interface and respond to test lifecycle events.
10. How would you design reporting for an enterprise framework?
A strong answer is:
“I would use HTML for human-readable investigation, JUnit for CI test results, JSON for dashboards, screenshots/videos/traces for failures, and CI artifacts for retention. For large suites, I would use parallel execution or sharding and merge reports when required.”
That answer demonstrates framework-level understanding.
Playwright Reporting Learning Roadmap for Beginners
If you are new to Playwright reporting, follow this sequence.
Level 1: Playwright Fundamentals
Learn:
- Playwright installation
- Locators
- Assertions
- Test hooks
- Fixtures
- Configuration
Related learning topics include Playwright Tutorial, Playwright Tutorial Step by Step, and Playwright TypeScript Tutorial.
Level 2: Reporting
Learn:
- HTML reporter
- List reporter
- JSON reporter
- JUnit reporter
- Screenshots
- Videos
- Trace Viewer
Level 3: Framework Design
Learn:
- Page Object Model
- Fixtures
- Test data
- Environment configuration
- Parallel execution
- Retry strategies
Level 4: CI/CD
Learn:
- GitHub Actions
- Jenkins
- Azure DevOps
- Docker
- CI artifacts
- Report retention
Level 5: Advanced Automation
Move into:
- Custom reporters
- API testing
- Sharding
- Blob reports
- Report merging
- Framework design
- Dashboard integration
Related topics worth learning include Playwright Python Tutorial, Playwright Java Tutorial, Playwright CI/CD Pipeline, Playwright GitHub Actions, Playwright Docker Tutorial, Playwright Page Object Model, Playwright Test Fixtures, Playwright Parallel Execution, Playwright Trace Viewer, Playwright Framework Design, Playwright API Testing, and Playwright Interview Questions.
FAQs: Playwright Reporting Tutorial
What is Playwright reporting?
Playwright reporting provides readable information about automated test execution, including results, errors, duration, steps, and debugging artifacts.
Is Playwright reporting suitable for beginners?
Yes. Beginners can start with the built-in HTML reporter and later learn JSON, JUnit, custom reporters, and CI/CD integration.
How do I get started with Playwright reporting?
Add an HTML reporter to playwright.config.ts, run:
npx playwright test
and open it with:
npx playwright show-report
How do I generate a Playwright HTML report?
Configure:
reporter: [[‘html’, { open: ‘never’ }]
and run your Playwright tests.
Can Playwright generate JSON and JUnit reports?
Yes.
reporter: [
[‘json’, { outputFile: ‘results.json’ }],
[‘junit’, { outputFile: ‘results.xml’ }]
]
Can Playwright reports contain screenshots and videos?
Yes. Configure screenshots and videos through the use section, commonly retaining them for failed tests.
Can Playwright reporting be used in CI/CD?
Yes. HTML reports, JUnit results, screenshots, videos, and traces can be preserved as CI artifacts. Playwright officially documents CI integrations including GitHub Actions and Azure Pipelines.
Can Playwright create custom reports?
Yes. Playwright supports custom reporter implementations using its Reporter interface.