WORKFLOW GUIDE

From shards to a reviewable packet.

1. Collect and inspect

Choose all candidate JUnit XML shards. Add the baseline from the same test scope if available. Each run may contain files from different CI systems. Use one local project per release comparison.

Review the leaf testcase counts and source audit. A suite's declared counts are checked against descendant testcase records; they never replace them. Invalid XML is retained as rejected evidence. It does not become a passing report.

2. Confirm test identities

The stable identity is the exact, case-sensitive tuple [suite ancestry, classname, name]. Filenames are only source labels. Missing suite names, testcase names or classnames need review. A root testcase has empty suite ancestry.

Use Review identity to inspect and override a record's fields. Suite ancestry is an ordered JSON array, for example ["Checkout", "API"]. Original XML and original identities are retained. Edits apply to one record; apply matching changes to the other run explicitly. Duplicate identities remain separate and ambiguous, even with the same outcome. They are never silently treated as retries.

3. Compare, annotate and export

After reviewing the audit, tick the review checkbox and compare. Add an assignee and investigation note to any identity. Export Markdown, CSV or a standalone HTML evidence report. The HTML report also contains original source XML as escaped text. Save a JSON backup to restore all sources, identity edits and notes into a separate project.

• New regression: baseline pass → candidate failure/error.
• Persistent failure / error: failure/error in both runs.
• Resolved: baseline failure/error → candidate pass only.
• No-baseline failure: candidate failure/error has no matching baseline.
• Missing from candidate: baseline identity is absent. This never means resolved.
• Not comparable: transitions such as skipped → failure or failure → skipped.
• Ambiguous: duplicate identities or incomplete identity fields.
• Unchecked: unsupported result semantics. Rejected/unsupported sources prevent complete cross-run assertions; otherwise classifiable comparisons are conservatively marked unchecked.

Count warnings must be reviewed but do not erase observed outcomes. Signature grouping normalizes numbers and hex addresses in error types/messages. It is only a search aid. The app does not infer flaky tests, a shared root cause, or permission to release.

Moving from the original address

Browser storage is separate for each domain. If you already have projects at our original address, open it in the same browser and choose Save backup for each project you want to move. Then open junit.outputchecks.com and choose Restore backup. Each backup adds a separate project; existing projects are preserved.

Your original browser data remains at the original address. We do not automatically redirect that address, copy your browser storage across domains, or upload your reports. Do not clear the old browser storage until you have checked your restored projects.

Supported input and limits

• UTF-8 .xml with optional UTF-8 declaration/BOM; roots testsuites, testsuite, or testcase. Nested suite containers are supported.
• Outcomes: failure, error, skipped; absent outcomes mean pass only in the supported subset. Mixed outcomes are unknown. Multiple messages with the same outcome are retained.
• Plain text, CDATA, standard XML entities and numeric references. DOCTYPE and entity declarations are rejected before parsing. External entities, namespaces, processing instructions and custom attributes/structures are unsupported. Embedded HTML is never executed.
• Common properties and system output are retained in source evidence; they are not used for identity or results. Attachments and URLs in logs are not fetched.
• Maximum 1 MiB per XML, 3 MiB current XML across 40 sources per project; nesting depth 64; 40,000 XML nodes and 10,000 testcases per source. Maximum 20 local projects. JSON backups up to 12 MiB. These are app safety limits, not JUnit standard limits.
• Time is seconds. Missing or invalid time remains unknown, distinct from an explicit 0. Test counts exclude unsupported nested testcase structures.
• Reports are synchronous, bounded local processing. Large reports may briefly occupy the tab. Split larger runs outside this app; never assume partial evidence covers a complete release.

Source or identity edits discard the old comparison and export preview. Cancelling an import, switching projects or changing evidence invalidates pending file reads. A failed backup restore leaves current projects untouched.

Established alternatives & sources

GitLab unit test reports are available in its Free tier and compare branch results. Its documentation warns that duplicate test names may cause later records to be ignored. For teams already in GitLab, that built-in workflow may be sufficient.

Testmo is a paid, fuller test-management platform with automation reporting and CI integration. Consult its own pricing rather than treating this tool as an equivalent replacement.

junit2html is a free MIT-licensed tool for self-contained HTML reports. Its README identifies GitLab as its maintained repository.

This workspace focuses on a cross-CI, browser-local evidence packet and explicit identity review. Free mature alternatives exist. Their existence does not validate demand, customer acquisition or revenue for this product. Sources reviewed 8 October 2026.