JUnit Reports: XML, HTML, and CI Test Reports Explained

What Is a JUnit Report?

JUnit itself produces events, not files. As the What Is JUnit chapter describes, the Platform publishes a start, pass, fail, or skip event for every container and test, and a listener turns those events into output. The listeners that matter in practice:

• The build tool's own listener - Maven Surefire and Gradle each write the familiar XML, one file per test class, in a format that predates JUnit 5 and that every CI server understands.
• The JUnit Platform's reporting module - junit-platform-reporting can write a legacy-format XML file per engine, or the newer Open Test Reporting XML with far more detail.
• The console summary - the per-class "Tests run: 3, Failures: 0" lines the build tool prints, which summarize the same events and are not a separate report.

The XML file is the one every other tool consumes. It is what a CI server parses to draw a trend graph, what a merge request shows as a test summary, and what a cloud grid merges across machines. The Jenkins JUnit plugin, whose whole job is to consume those files, is installed on 96.5% of Jenkins controllers according to the plugin site, which says how standard the format has become beyond Java.

Surefire XML Report Anatomy

The file below is TEST-demo.CalculatorTest.xml exactly as Surefire 3.6.0 wrote it when I ran the tutorial's three-test Calculator class on a TestMu AI HyperExecute Linux VM (job 4b625bc7, Java 17.0.16). The 52 property elements that record the JVM's system properties are cut; nothing else is:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report.xsd"
           version="3.0.2" name="demo.CalculatorTest" time="0.08"
           tests="3" errors="0" skipped="0" failures="0" flakes="0">
  <properties>
    <!-- 52 <property name="..." value="..."/> elements: java.version, os.name, user.dir, ... -->
  </properties>
  <testcase name="rejectsZeroDivisor" classname="demo.CalculatorTest" time="0.042"/>
  <testcase name="addsTwoNumbers" classname="demo.CalculatorTest" time="0.002"/>
  <testcase name="dividesTwoNumbers" classname="demo.CalculatorTest" time="0.002"/>
</testsuite>

The names in that file are method names, not the @DisplayName values; "divide() rejects a zero divisor" appears only in the Open Test Reporting file below, so a team that relies on display names for readable CI output needs the newer format or an IDE. And the schema reference points at Surefire's own XSD, because there is no official JUnit XML standard: Surefire's schema is the de facto one that other tools, including pytest and Playwright reporters, imitate.

Legacy XML vs Open Test Reporting

The JUnit Platform Reporting page in the user guide documents two formats from the junit-platform-reporting artifact. LegacyXmlReportGeneratingListener writes the Surefire-compatible format, one file per engine, and is what the Console Launcher uses. OpenTestReportGeneratingListener writes Open Test Reporting XML and is auto-registered once the artifact is on the test classpath, but it stays off until you enable it.

Enabling it took two lines in src/test/resources/junit-platform.properties and the dependency from the JUnit Maven Dependency chapter's bom:

# src/test/resources/junit-platform.properties
junit.platform.reporting.open.xml.enabled=true
junit.platform.reporting.output.dir=target/open-test-report

The same run then produced a second file. It is 3,985 bytes against the Surefire file's 7,570, because it skips the system properties, and it records what the legacy file cannot:

<?xml version="1.0" ?>
<e:events xmlns="https://schemas.opentest4j.org/reporting/core/0.2.0"
          xmlns:e="https://schemas.opentest4j.org/reporting/events/0.2.0" ...>
<infrastructure><hostName>prod-hyperexecute-linux-dynamic-spot-1-v1633797</hostName><userName>ltuser</userName>
  <operatingSystem>Linux</operatingSystem><cpuCores>4</cpuCores><java:javaVersion>17.0.16</java:javaVersion>...</infrastructure>
<e:started id="1" name="JUnit Jupiter" time="2026-10-07T12:01:44.429913908Z">...</e:started>
<e:started id="2" name="CalculatorTest" parentId="1" time="2026-10-07T12:01:44.461808035Z">...</e:started>
<e:started id="3" name="divide() rejects a zero divisor" parentId="2" time="2026-10-07T12:01:44.489002314Z">
  <metadata><junit:uniqueId>[engine:junit-jupiter]/[class:demo.CalculatorTest]/[method:rejectsZeroDivisor()]</junit:uniqueId>...</metadata>
</e:started>
<e:finished id="3" time="2026-10-07T12:01:44.534884022Z"><result status="SUCCESSFUL"></result></e:finished>
...
<e:finished id="1" time="2026-10-07T12:01:44.556456068Z"><result status="SUCCESSFUL"></result></e:finished>
</e:events>

Use the legacy file for anything a CI server will parse today, and switch the Open Test Reporting file on when you need display names, nested structure, or the host that ran a flaky test; the two coexist in the same build.

HTML Reports With the Surefire Report Plugin

Neither JUnit nor Surefire writes HTML during the test phase. The Maven Surefire Report plugin does it afterwards: it reads the XML files and generates target/reports/surefire.html, either standalone with mvn surefire-report:report or as part of mvn site when the plugin sits in the pom's reporting section:

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-report-plugin</artifactId>
      <version>3.6.0</version>
    </plugin>
  </plugins>
</reporting>

The page it produces is a summary table, a per-package breakdown, and the failure text per test. It is enough for a nightly email and not enough for a browser suite that needs screenshots and step logs; those come from Allure or ExtentReports, or from the test platform. The TestNG side of this tutorial covers the equivalent setup in TestNG Reports in Jenkins, and coverage numbers, which are a separate report, are the subject of code coverage with Maven and JaCoCo.

Publish JUnit Reports in Jenkins, GitHub Actions, and GitLab

All three publishers take the same input, the Surefire XML, and differ only in syntax and in what they do with it. The step always runs after the tests and always runs even when they fail; a publisher that is skipped on failure is useless on exactly the build you need it for.

# Jenkins declarative pipeline (JUnit plugin)
stage('Test') {
  steps { sh 'mvn -B test' }
  post {
    always {
      junit testResults: 'target/surefire-reports/*.xml', allowEmptyResults: false
    }
  }
}

# GitHub Actions (dorny/test-reporter)
- name: Run tests
  run: mvn -B test
- name: Publish test results
  uses: dorny/test-reporter@v3
  if: always()
  with:
    name: JUnit Results
    path: target/surefire-reports/TEST-*.xml
    reporter: java-junit

# GitLab CI
test:
  stage: test
  script:
    - mvn -B test
  artifacts:
    when: always
    reports:
      junit: target/surefire-reports/TEST-*.xml

If the suite runs from a shell rather than a build tool, the Run JUnit from Command Line chapter shows the Console Launcher flags that write the legacy XML to a directory of your choice, which the same publishers then read.

Reports at Scale: Many Machines, One Result

Reports get harder the moment a suite runs on more than one machine, because each VM writes its own target/surefire-reports and nothing merges them. HyperExecute treats that as part of the run: a partialReports block in hyperexecute.yaml names the report location and framework, the platform collects the files from every task, merges them into one job report, and separates retried attempts so a pass rate is not inflated by reruns. The HyperExecute JUnit XML report documentation shows the four-line configuration:

report: true
partialReports:
    frameworkName: junit
    location: reports/
    type: xml

The location accepts glob wildcards, which is the fix for a report directory named with a date or an environment, and partialReports takes a list, so a job can emit JUnit XML for the CI server and an HTML report for people at the same time. Reports, logs, screenshots, and video download as one archive from the dashboard or with the CLI's --download-report and --download-artifacts flags. The job that produced the XML in this chapter finished in 42 seconds end to end, including VM provisioning and the dependency cache restore.

Note: See every JUnit result from every machine in one report on TestMu AI, with the same reports your CI already reads. Try TestMu AI free!

Troubleshooting Missing or Wrong Reports

Best Practices for JUnit Reports

• Publish on every outcome - the CI publish step belongs in an always block; a report that only exists for green builds answers no questions.
• Keep the XML as a build artifact - the files are small, and a report from last Tuesday is often the fastest way to prove when a test started failing.
• Name tests for the report, not the IDE - method names reach the legacy XML; write them so a failure line reads as a sentence.
• Watch flakes as closely as failures - a retry that passes is a bug that got lucky; track the attribute or disable reruns in CI.
• Switch on Open Test Reporting for browser suites - the host and timing detail is what you need when a test fails only on one agent.
• Merge before you read - with parallel VMs, publish one merged report rather than one per machine, or the trend graphs lie.

Conclusion

Open target/surefire-reports after your next run and read one TEST-*.xml file against the table above; once the attributes make sense, every CI test view is a rendering of that JUnit report. Then add the publisher for your CI server in an always block, and enable Open Test Reporting when method names stop being enough.

The next chapter, JUnit with Selenium, moves from unit tests to browser tests, where screenshots and video join the XML as evidence. For suites that already run on many machines, the HyperExecute documentation linked above shows the one-file setup that merges the reports.