Publishing Test Reports and Results

A passing or failing exit code is the bare minimum; published reports show *which* tests failed and why, right where you are looking.

When a build goes red, you want to know what broke without digging through raw logs. Publishing structured test reports surfaces results on the pull request and in run summaries. This lesson covers generating reports and making them visible.

Standard report formats

Most test runners can emit results in a standard machine-readable format - JUnit XML is the most widely supported, with formats like TAP and JSON also common. These structured outputs are what reporting tools consume to build human-friendly summaries. Configure your runner to write one out as part of the test step.

emit a JUnit report

steps:
  - run: npm test -- --reporters=default --reporters=jest-junit
    env:
      JEST_JUNIT_OUTPUT: reports/junit.xml

Publishing to the pull request

A reporting action reads the JUnit file and posts a summary as a PR check or comment, listing failed tests with their messages. This means a reviewer sees exactly what failed without opening the logs. There are several Marketplace actions for this; they all take the path to your report file.

Using the job summary

GitHub Actions lets any step write Markdown to a job summary that appears at the top of the run. You can write a short results table there so the outcome is visible the instant you open the run, no scrolling required.

writing a job summary

steps:
  - run: |
      echo "## Test results" >> "$GITHUB_STEP_SUMMARY"
      echo "- Passed: 142" >> "$GITHUB_STEP_SUMMARY"
      echo "- Failed: 0" >> "$GITHUB_STEP_SUMMARY"

Keeping artifacts for deeper inspection

Upload the full report and any screenshots or logs as artifacts for failures.
Set a short retention on bulky reports to control storage cost.
Combine reports across sharded jobs into one summary so nothing is hidden.
Surface the failing test name and message up front; keep the noise in the artifact.

Key takeaways

Emit a standard format like JUnit XML so tools can parse your results.
Reporting actions post failed tests directly onto the pull request.
Write a quick summary to GITHUB_STEP_SUMMARY and keep full reports as artifacts.