JUnit XML report
A JUnit XML report is an XML file of test suites and test cases with each case's name, duration and outcome, plus failure messages and stack traces. It started with Java's JUnit and Ant and became the de facto exchange format for test results, so most runners can write it and most CI servers and test management tools can read it.
Also called: JUnit XML, XML test report
Why it became the default
JUnit XML was never a formal standard, but almost every CI server and test management tool can read it, so almost every test runner learned to write it. pytest writes it with --junitxml, TestNG and Maven Surefire write it by default, and Jest, Vitest, Newman and many others produce it through a built-in or community reporter. For a team with several stacks, it is often the one format that every pipeline can emit.
What it carries
A report is a tree of test suites and test cases. Each case has a name, a class or file, a duration and an outcome: passed, failed with a message and stack trace, errored, or skipped. Many runners add properties, standard output and system error text. That is enough to count results, spot slow tests and track failures over time.
What it leaves out
Screenshots, videos and traces are not part of the format, so a failure arrives as text only unless the tool uploads artifacts separately. Retries are represented differently from runner to runner, which can make one flaky test look like two results. Links to documented test cases also depend on conventions, such as an ID in the test name or a property, because the format has no field for them. See test case ID.
Using it with a test management system
Uploading JUnit XML is the widest path into a test management system for runners without a dedicated reporter. How results then flow from CI into the test record is covered in managing automated test results in a TMS.