Test Reporting & PR Status Checks

📌 Definition:

📖 Detailed Explanation:

A test run that only prints to a log is nearly useless at scale. Reporting operates at three levels. First, machine-readable output (JUnit XML, JSON) that dashboards and the CI platform parse to show pass/fail counts, durations and trends. Second, status checks: each job reports a commit status, and these surface directly on the PR as required checks that gate merge. Third, developer-facing detail: an HTML report with traces, or inline PR annotations that point to the exact failing assertion and line. Good reporting shortens the loop from 'the build is red' to 'this specific test failed here for this reason' without the developer digging through logs. It's also what makes quality gates enforceable, because a gate needs a concrete signal to block on.

🔑 Key Points:

• Emit machine-readable results (JUnit/JSON) for dashboards and trends
• Status checks report per-job pass/fail onto the PR and can gate merge
• Developer detail: HTML reports with traces, or inline PR annotations
• Good reporting turns 'build red' into 'this test failed here, because X'
• Reporting is the foundation quality gates and required checks build on

🌍 Real-World Example:

📎 Code Example:

# Emit JUnit for the platform + a rich report for humans
- run: npx playwright test --reporter=junit,html
  env:
    PLAYWRIGHT_JUNIT_OUTPUT_NAME: results/junit.xml

# Surface failures inline on the PR (GitHub reporter or an action)
# playwright.config: reporter: [['github'], ['junit', { outputFile: 'results/junit.xml' }], ['html']]

- name: Publish test results to the PR
  if: ${{ !cancelled() }}
  uses: actions/upload-artifact@v4
  with: { name: junit, path: results/junit.xml }