JUnit XSD file

[Paebbels]

Maybe a JUnit XSD file might be interesting for you too: https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd

Maybe you could align on a license (see also #1)

[pmhahn]

There also is the Junit 5 XSD:

• This file available under the terms of the MIT License.
• many more (optional) attributes
• most attributes typed as string 😦

[Paebbels]

To be more correct, this is not a JUnit 5 XML format, but a Jenkins made XML format for JUnit. So it's a Jenkins dialect for "JUnit XML". To my knowledge, the official format is Open Test Reporting (OTR): https://github.com/ota4j-team/open-test-reporting . OTR has a generic structure and a Java specific extension.

Also, the so called JUnit XML is not made by JUnit, but by Ant for there JUnit build step. So it should be called more like Ant JUnit XML format.

---

Using strings for every type shows how little knowledge Jenkins has in XML formats ...

[Paebbels]

@pmhahn:
Addendum, it's saved in the JUnit 5 repository, but it's original source shows, it's an XSD for JUnit 4.

From XSD file: https://svn.jenkins-ci.org/trunk/hudson/dtkit/dtkit-format/dtkit-junit-model/src/main/resources/com/thalesgroup/dtkit/junit/model/xsd/junit-4.xsd

Also this file was created by the Thales Group.

[pmhahn]

From XSD file: https://svn.jenkins-ci.org/trunk/hudson/dtkit/dtkit-format/dtkit-junit-model/src/main/resources/com/thalesgroup/dtkit/junit/model/xsd/junit-4.xsd

Sadly that link is broken; see https://github.com/Vlatombe/lib-dtkit-format/tree/master/dtkit-junit-model/src/main/resources/com/thalesgroup/dtkit/junit/model/xsd possible alternatives.

By searching for junit-4.xsd I stumbled over https://llg.cubic.org/docs/junit/, which also contains a XSD and an example XML with one big difference: it uses @disabled instead of @skipped.

PS: I only stumbled over this issue here while doing my research for GitLab#299086: Clarify JUnit XML format to write a tap2junit-xml converter myself

[Paebbels]

@pmhahn if you like, we can meet in Zoom and discuss what I figured out at my research for different JUnit dialects. My GitHub username is also my google email address.

I implemented a converter tool in pyEDAA.Reports. I couldn't find any evidence for testmo's claim for nested testsuite elements. This would be nice and it would be a clean structure, but all implementation I tested so far, use dot-notation in the class field. Many tools display a flat hierarchy, others like PyCharm show a nice testcase tree.

My tools also contains multiple XSD files to reflect the JUnit dialects.

My main goal was to write a merge operation, because most tools claiming a merge operation, actually performe a join operation. The tool can also strip unnecessary hierarchy (deep nesting until the tree splits into branches) like produced by pytest. Another feature is setting the top-level name or transforming init entries to the correct tree-level (again pytest).

Such a modified JUnit test summary can then be visualized in e.g. Sphinx like here: https://edaa-org.github.io/pyEDAA.Reports/unittests/index.html