Playwright test evidence

01

Write JUnit XML from Playwright

Configure the reporter once in playwright.config.ts. A list reporter keeps console output readable, JUnit XML supplies portable test results, and the HTML report remains optional diagnostic evidence.

import { defineConfig } from '@playwright/test'

export default defineConfig({
  reporter: [
    ['list'],
    ['junit', { outputFile: 'artifacts/junit/playwright-junit.xml' }],
    ['html', { outputFolder: 'artifacts/html-report', open: 'never' }],
  ],
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'retain-on-failure',
  },
  outputDir: 'artifacts/test-results',
})

For a one-off run or an existing shared config, the reporter can also be set from CI:

PLAYWRIGHT_JUNIT_OUTPUT_FILE=artifacts/junit/playwright-junit.xml   npx playwright test --reporter=junit

Framework reference: Playwright JUnit reporter.

02

Retain the output in your provider

Creating a local XML file is only half of the integration. The pipeline must retain it after the job completes so QaCockpit can retrieve the exact run evidence.

03

Keep browser evidence connected to failures

JUnit explains the test identity and failure output. Screenshots, video, traces, and Playwright's error context shorten diagnosis when they come from the same attempt. Retain them beside the XML without embedding secrets or production customer data.

• Use screenshots only on failure to keep artifacts focused.
• Retain video and trace on failure or first retry according to your team's policy.
• Keep the Playwright project or browser in the test identity or execution context.
• Use a unique artifact name for each matrix job or shard.

04

Inspect a complete public example

The synthetic demo runs against a local fixture and contains no QaCockpit credentials, private product code, or customer data. It exposes stable green, failed-test, and scope-drift scenarios through typed workflow_dispatch inputs.

Continue with the Test Scope guide orFailure Inbox article.