[FEATURE] Official Playwright reporter package

[therealbrad]

Feature Summary

A first-party Playwright reporter package (@testplanit/playwright-testplanit-reporter) that submits Playwright results directly to TestPlanIt, alongside the existing @testplanit/wdio-testplanit-reporter.

Problem Statement

Current Situation

Playwright users can already ship results to TestPlanIt by running Playwright's built-in JUnit reporter and ingesting the XML via @testplanit/cli. That works, but:

• It's a two-step CI flow (run tests → write JUnit XML → CLI upload) instead of an in-process push.
• Playwright-specific signal is lost in the JUnit hop: test.step() step-level results, test.annotation entries, test.use() metadata, attached screenshots / videos / traces, and project naming all get flattened.
• Customers comparing TestPlanIt to other tools see "native WDIO reporter, no native Playwright reporter" and read that as parity gap.

Desired Outcome

A native Playwright reporter that:

• Submits results in-process at the end of a Playwright run, no CI bridge required.
• Captures Playwright-specific signal (steps, annotations, attachments).
• Maps Playwright projects to TestPlanIt runs cleanly.
• Honors the same case-ID matching the test-results importer added in enhancement(import): link JUnit/CLI results to existing cases by ID #394 / enhancement(import): add case-ID matching controls to the web import dialog #395 ([123], C123, TC-123 formats and test_id / testplanit_case_id properties) so renaming a Playwright test doesn't duplicate the case.

Proposed Solution

A new workspace package packages/playwright-testplanit-reporter/ that implements Playwright's Reporter interface (onBegin, onTestEnd, onEnd, etc.) and pushes payloads to the same TestPlanIt API endpoints the WDIO reporter uses.

Likely capture surface (informed by what Playwright exposes natively):

• Test outcome + duration + retry count
• Step-level results from test.step()
• Annotations (test.annotation) for tags + linked issue keys
• Screenshots, videos, traces attached as result attachments
• test.use() metadata for run-level naming and tagging
• project name → run naming convention (one TestPlanIt run per Playwright project, configurable)
• Case-ID matching consistent with the test-results importer presets so renames don't duplicate cases

User Story

As a QA engineer running Playwright in CI, I want an official @testplanit/playwright-testplanit-reporter so that my Playwright suite uploads results to TestPlanIt directly with steps, annotations, and attachments preserved, without a CI bridge step.

Acceptance Criteria

• @testplanit/playwright-testplanit-reporter published to npm with provenance (OIDC trusted publishing)
• Configurable via playwright.config.ts reporter: [['@testplanit/playwright-testplanit-reporter', { ... }]]
• Captures step-level results from test.step()
• Captures test.annotation entries (mapped to tags + linked issues)
• Attaches Playwright artifacts (screenshots, videos, traces) to results
• Maps Playwright project → TestPlanIt run (configurable)
• Supports case-ID matching consistent with the test-results importer ([123], C123, TC-123, test_id / testplanit_case_id)
• Documentation page alongside the WDIO reporter doc
• E2E coverage that runs Playwright against the reporter and asserts a result lands in TestPlanIt

Alternative Solutions

Option 1: keep using Playwright's JUnit reporter + @testplanit/cli

Status quo. Works today, but loses the Playwright-specific signal listed above and requires a CI bridge step.

Option 2: publish a community recipe instead of a package

Document the JUnit-to-CLI flow as the recommended path. Cheapest, but doesn't close the parity gap with the native WDIO reporter and gives up the Playwright-specific signal permanently.

Technical Considerations

Dependencies

• Requires API changes — no (existing result-submission endpoints are sufficient; the WDIO reporter uses the same surface)
• Requires third-party integration — yes (@playwright/test Reporter interface)
• Requires database schema changes
• Requires UI/UX design review

Architectural template: packages/wdio-testplanit-reporter/ (≈3500 LOC across service.ts, shared.ts, types.ts, shared.test.ts). The API-calling layer should be shared with the WDIO reporter and the test-results importer.

Performance Impact

In-process result submission per test end; no expected impact on Playwright test execution beyond the network call. Batching at onEnd is an option if per-test calls are too chatty against large suites.

Security Considerations

API token handling consistent with the WDIO reporter (reads from env vars; no token surfaces in logs or attachment metadata).

Business Value

Priority

• Critical
• High — Significant improvement (parity gap with the native WDIO reporter; Playwright is widely used in JS test automation)
• Medium
• Low

Affected User Groups

• QA Engineers
• Developers
• Test Managers
• Project Managers
• Stakeholders

Expected Usage

• Daily — every CI run for any project using Playwright + TestPlanIt

Implementation Effort

• Small (1–2 days)
• Medium (3–5 days)
• Large (1–2 weeks) — parallel scope to the WDIO reporter
• Extra Large

Related Issues/Features

• Related to enhancement(import): link JUnit/CLI results to existing cases by ID #394 (case-ID matching in the test-results importer)
• Related to enhancement(import): add case-ID matching controls to the web import dialog #395 (case-ID matching controls in the web Import dialog)
• Related to the existing @testplanit/wdio-testplanit-reporter package (architectural template)

Additional Context

Customer feedback raised this on 2026-06-04, framed as: "I think it's nice we have a wdio reporter, but I'd like to see an official Playwright reporter, given it's a more widely used automation tool."

Examples from Other Tools

• Playwright maintains a published reporter interface and a small ecosystem of third-party reporters (Allure, ReportPortal, currents.dev), so the surface is well-documented.
• Comparable test-management tools that ship a native Playwright reporter: Xray, Zephyr Scale (community-maintained), qase.io, TestRail (community).