XML format
JUnit XML
JUnit test-result XML used by CI systems: suites contain cases, and failures, errors, or skips are child elements rather than status attributes.
JUnit XML is a family of compatible conventions rather than one versioned standard. A top-level <testsuites> commonly groups <testsuite> elements, which in turn contain <testcase> records and optional failure, error, or skipped children.
The shared core travels well between build systems, but extensions do not. Producers add properties, captured output, timestamps, file paths, and vendor-specific attributes, so consumers should preserve unknown fields and tolerate a single <testsuite> root.
- Accept both <testsuites> and a single <testsuite> in real integrations.
- A testcase's outcome is represented by a <failure>, <error>, or <skipped> child; no child normally means success.
- Counts and durations are frequently missing or inconsistent, so derive them from cases when accuracy matters.
- system-out and system-err may contain large text payloads and CDATA edge cases.
- Root element
<testsuites>- Media type
application/xml- Extensions
.xml- Namespaces
- None — unqualified elements
- XMLDir label
xml
A minimal valid document
Every example on this site is checked against the same parser the workspace uses, so what you see below is known to be well-formed.
<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="2" failures="1" time="0.14">
<testsuite name="cart" tests="2" failures="1" time="0.14">
<testcase classname="Cart" name="adds an item" time="0.04"/>
<testcase classname="Cart" name="rejects a bad quantity" time="0.10">
<failure message="expected validation error">Assertion failed</failure>
</testcase>
</testsuite>
</testsuites>Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.