Test tooling spends most of its life reading other tools' output, and that output is exactly what nobody publishes a sample of. This category ships the report formats a CI dashboard, a coverage gate, or a flaky-test detector has to parse: JUnit and NUnit XML, MSTest TRX, TAP streams, Cucumber and Playwright JSON, Gherkin feature files, and Robot Framework suites. Coverage arrives as Cobertura, JaCoCo and Clover XML alongside LCOV tracefiles and Istanbul JSON, with matching totals across formats so a converter can be diffed against a known answer. Performance and network fixtures round it out, HAR captures, load-test summaries, and timing tables. Passing, failing, skipped, and intentionally malformed reports are all labelled, so a parser can be held to the difference.
Filter testing & qa on Browse · 142 files · 10 subcategories
Results start with a representative from each related test family. Use a card’s variant menu or the filters below to reach a specific format, profile, or failure case; every sample retains its own detail page and download.
JUnit and NUnit XML, MSTest TRX, TAP, Cucumber and Playwright JSON, Gherkin .feature files, and Robot Framework suites, plus Cobertura, JaCoCo, Clover, LCOV, and Istanbul JSON for coverage.
Yes. Coverage fixtures in different formats describe the same fictional source tree with the same totals, so you can run a converter and assert the numbers survive the round trip.
Yes, passing, failing, skipped, and flaky runs, plus intentionally malformed reports labelled as such in title and description so a parser can be tested for failing loudly.
Start with one example from each use-case group, then continue through its other test families. Choose a use case, search, or filter to find a specific profile; a card’s variant menu contains its related samples.
27 test families · 142 available files · Page 1 of 2
Bdd
One step of one scenario fails with an assertion message and a stack frame; every other step passes. In cucumber.json a scenario has no status of its own (it is failed if any of its steps is), so this file catches report
Corrupt
An intentionally corrupt JUnit report: the file ends in the middle of a testcase attribute value, exactly as it would if the CI worker were killed while the reporter was still writing. Three elements are left unclosed an
Coverage
Three named test runs in one tracefile, each covering a different part of the tree, reported via the TN: record most tools quietly discard. Keeping the name is what lets a report answer which suite covered a given line.
Flaky Runs
Forty builds of six tests, one JSON object per line, with three tests that fail intermittently and three that never do. This is the input shape a flake detector ingests; the CSV twin in this group holds the aggregate it
Har
A PNG response whose body is carried as base64 with content.encoding set accordingly. content.size is the DECODED byte count, not the length of the base64 string, which is the field readers most often get wrong when comp
Junit XML
The same 12-case Novus Checkout run written the way @playwright/test 1.47 junit reporter writes it. Playwright puts the run totals on the <testsuites> root, names each suite after its spec file, and uses the bare describ
Performance
The percentile table a performance report renders as a chart, with mean, p50, p95, p99 and max for each of the four scenarios. The same numbers appear inside the JSON summary in this group, so a chart built from either s
Plans
Thirteen requirements mapped to the test cases that cover them, and one, REQ-PAY-02, deliberately covered by nothing. A coverage-gap report that does not surface that row is not working, which makes this the answer key f
Runners
Jest's --json output, where skipped tests are called pending and the totals appear as flat numTotal/numPassed/numFailed fields alongside per-file assertionResults. Timestamps are epoch milliseconds rather than ISO string
Tap
A run abandoned after the third assertion with a Bail out! line, leaving five of the planned eight assertions unreported. The run is a failure even though only one assertion said not ok, and a consumer must not report 2/
Bdd
The legacy cucumber.json report for the same run: the format nearly every BDD dashboard still ingests. Durations are in nanoseconds here and in a nested {seconds, nanos} object in the messages twin, which is the single m
Coverage
The Clover serialisation, whose <metrics> element rolls statements, conditionals and methods into a single elements/coveredelements pair. Anything reading only that pair reports a blended percentage that matches none of
Flaky Runs
Build #301 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host in
Har
A conditional request answered 304 with full beforeRequest and afterRequest cache state, next to a first-time fetch whose beforeRequest is null. The null is the documented way to say "not in the cache", and readers that
Junit XML
240 cases across six classes, three of them failing. Big enough to time a parser and to check that a report UI paginates or virtualises rather than rendering every row, but still small enough to read.
Runners
The pytest-json-report document, which records setup, call and teardown as three separate phases per test and keeps error distinct from failed in its summary. A test can pass its call phase and still error in teardown, w
Tap
A whole suite declined in a single line: a zero-length plan with a SKIP directive and a reason. It is a valid, complete TAP stream containing no assertions, and a consumer must report it as skipped rather than as an empt
Bdd
A feature written entirely in French keywords, declared by the # language: fr header that must be the first line of the file. Parsers that hardcode English keywords read this as a feature with no scenarios rather than re
The use-case group filter replaces the long list of category sections.
