Browse testing · Novus Examples

Coverage — Clover XML

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 the other three formats unless the components are separated first. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura at Zero Coverage

A structurally complete Cobertura report in which line-rate and branch-rate are 0.0 everywhere. The counterpart to the zero-coverage LCOV file, for checking that a converter keeps the class and method structure when there is nothing covered to describe.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura Condition-Coverage Attributes

Cobertura with a condition-coverage attribute on every branching line, written in the "50% (1/2)" form. The percentage and the fraction can disagree in real reports, so a parser should read the fraction and treat the percentage as derived.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura with One Package per Directory

The same coverage split into one package per source directory with dotted names, the layout a JVM project produces. Reports that key on class name alone collide as soon as two packages hold a class of the same name, which this file is shaped to expose.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura with Several Source Roots

Three <source> roots with class filenames given relative to them, which is how Cobertura represents a multi-root project. A viewer must try each root in turn to resolve a file; one that assumes a single root shows "source not found" for most of the report.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Cobertura XML

The Cobertura serialisation of the same run, with packages, classes, per-method line rates and condition-coverage attributes on every branching line. Cobertura expresses coverage as rates rather than counts, so this is the file that catches converters rounding a percentage into a hit count. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — Gate Boundary at 79.29% (misses the gate by one line)

A tracefile sitting misses the gate by one line against the 80% minimum in this group's gate config: 111 of 140 lines, 79.29%. 79.29% is one covered line short of the gate, the smallest possible failure.

File: LCOV · Coverage · 4 records
Use case: Conversion testingConfig testing+1· Conversion set

Coverage — Gate Boundary at 80.00% (meets the gate exactly)

A tracefile sitting meets the gate exactly against the 80% minimum in this group's gate config: 112 of 140 lines, 80.00%. 80.00% is exactly the configured minimum, so a > comparison fails the build and a >= comparison passes it — the single most common off-by-one in a coverage gate.

File: LCOV · Coverage · 4 records
Use case: Conversion testingConfig testing+1· Conversion set

Coverage — Gate Boundary at 80.71% (clears the gate by one line)

A tracefile sitting clears the gate by one line against the 80% minimum in this group's gate config: 113 of 140 lines, 80.71%. 80.71% clears the gate by one covered line, the smallest possible pass.

File: LCOV · Coverage · 4 records
Use case: Conversion testingConfig testing+1· Conversion set

Coverage — Gate Configuration (JSON)

The threshold configuration the three boundary tracefiles in this group are meant to be judged against: global minimums, one per-path override and an explicit >= comparison. Publishing the comparison operator is the point — leaving it implicit is what makes an at-the-gate report ambiguous.

File: JSON · Coverage
Use case: Config parsingJSON parsing+1· Conversion set

Coverage — Istanbul coverage-final.json

The raw Istanbul document nyc and Jest write before any reporter runs: statementMap, fnMap and branchMap giving source locations, with the s, f and b objects holding the hit counts. Branch counts here are arrays per branch point, which is why converting to LCOV doubles the branch total if the array is not flattened. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: JSON · Coverage
Use case: JSON parsingConversion testing+1· Conversion set

Coverage — Istanbul JSON Summary

The compact json-summary reporter output: a total block plus one block per file, each with lines, statements, functions and branches as total/covered/skipped/pct. This is what coverage badges and pull-request comments are generated from. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: JSON · Coverage
Use case: JSON parsingConversion testing+1· Conversion set

Coverage — JaCoCo Method-Level Counters

Per-method INSTRUCTION, LINE, COMPLEXITY and METHOD counters for all 20 methods, 2 of which were never entered. This is the detail a "which functions are untested" report needs and the level at which most converters stop.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo Multi-Module <group>

The aggregate form a multi-module build produces: packages nested inside a <group> rather than directly under <report>. Parsers with a hardcoded report/package path find nothing here and report a module with no coverage at all.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo with Every Counter Type

All six JaCoCo counter types present at every level of the document — method, class, sourcefile, package and report. Tools usually read only the report-level LINE counter; this file is for checking that per-method and per-package rollups agree with it.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo with Several Session Records

A report merged from three separate JVM sessions, each recorded as its own <sessioninfo> with start and dump timestamps. The counters are already the merged totals, so summing per-session anything from this file is a mistake it exists to catch.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — JaCoCo XML

The JaCoCo serialisation, which reports missed/covered pairs rather than found/hit and adds INSTRUCTION and COMPLEXITY counters no other format carries. Converters routinely swap missed for covered here, which inverts the whole report. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: XML · Coverage
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV at 100%

Every line hit at least once, so LH equals LF exactly. The upper-bound control for a coverage gate, and the case that catches percentage formatting that renders 100% as 100.0% or, worse, rounds 99.95% up to it.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV at Zero Coverage

Every instrumented line present with a hit count of zero — the shape of a report from a run in which the tests never loaded the instrumented code. It is not an empty file, and conflating the two hides a broken test harness behind a missing-report warning.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV Tracefile with BRDA Branch Records

The reference LCOV tracefile: one record per source file with FN/FNDA function records, real BRDA branch records (block, branch and taken count, with '-' for a branch never reached) and DA line hits, closed by the LF/LH, FNF/FNH and BRF/BRH counters. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV with Function Records Only

Records containing FN/FNDA/FNF/FNH and nothing else: no DA lines, no LF or LH. Merge tools that assume every record ends with LF/LH either crash here or invent a zero line count for a file that simply was not line-instrumented.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV with Several TN: Test Names

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.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV with Two Test Runs Over the Same Files

Two TN: blocks — a unit run and an integration run — each carrying a full record for the same two source files. A correct merge sums the DA hit counts per line and recomputes LH; a tool that keeps the last record seen throws away the unit run entirely.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Coverage — LCOV Without Branch Records

The same tracefile with every BRDA, BRF and BRH line removed — what a runner emits when branch instrumentation is off. A gate that reads branch coverage from this file must report it as unavailable, not as 0%, or an unconfigured project looks like a badly tested one.

File: LCOV · Coverage · 4 records
Use case: Conversion testingCode parsing+1· Conversion set

Explore the test library

Filter the library

142 results