LCOV — Lines Hit Exceeds Lines Found (intentionally corrupt)
An intentionally corrupt LCOV tracefile: every record declares LH eight greater than LF, so more lines were hit than exist. The syntax is perfectly valid, which is the point — the contradiction is semantic, and a coverage gate that trusts the summary counters computes over 100% coverage and passes a build it should have stopped. Recompute LH from the DA lines and the real figure is 127/140.
TN:novus-checkout-unit
SF:src/cart/pricing.js
DA:2,13
DA:3,21
DA:4,23
DA:5,10
DA:6,8
DA:8,2
DA:9,47
DA:10,2
DA:11,0
DA:12,29
DA:13,41
DA:15,14
DA:16,36
DA:17,40
DA:18,5
DA:19,33
DA:20,0
DA:22,47
DA:23,18
DA:24,29
DA:25,18
DA:26,42
DA:27,17
DA:29,33
DA:30,0
DA:31,31
DA:32,42
DA:33,9
DA:34,13
DA:36,45
DA:37,16
DA:38,20
DA:39,0
DA:40,18
DA:41,24
DA:43,15
DA:44,30
DA:45,33
DA:46,16
DA:47,9
DA:48,46
DA:50,15
DA:51,15
DA:52,2
LF:44
LH:52
end_of_record
TN:novus-checkout-unitSpecifications
- Seed
- 61200
- Intentionally Corrupt
- true
- Damage
- LH is 8 greater than LF in every record
- Records
- 4
- Declared Lines Found
- 140
- Declared Lines Hit
- 172
- Implied Coverage Pct
- 122.86
- Syntactically Valid
- true
- Line Endings
- LF
Testing contract
Expected to fail- Scenario
- Validate an LCOV tracefile whose summary counters contradict its detail lines.
- Expected result
- LH is rejected as impossible (greater than LF) and, if recovery is attempted, LH is recomputed from the DA lines as 127 rather than trusted as declared.
What is a .lcov file?
LCOV is a plain-text code-coverage tracefile format originally produced by the Linux Test Project's front end for gcov and now emitted by tooling across many languages. Records are grouped per source file between an `SF:` line and an `end_of_record` line, with `DA:` lines giving per-line hit counts, `FN:`/`FNDA:` lines covering functions, `BRDA:` lines covering branches, and `LF`/`LH`, `FNF`/`FNH`, `BRF`/`BRH` summary counters.
How to use this file
Use an example .lcov file to test coverage viewers, merge tools, and CI coverage gates — verifying that summary counters match the detail lines, that multiple source records are merged rather than overwritten, and that branch data survives conversion to Cobertura or JSON.
How to use this file for testing
“LCOV — Lines Hit Exceeds Lines Found (intentionally corrupt)” is a deterministic Novus Examples fixture for Error handling, Conversion testing, Schema validation. Deliberately corrupt and invalid files, clearly labelled, for testing how your tool fails.
Documented properties for this file: seed 61200 · damage: LH is 8 greater than LF in every record · 4 records · LF · intentionally corrupt. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Test and coverage reports document their totals (suites, cases, passes, failures, skips, covered lines) in the spec table. Point your CI dashboard, coverage gate, or report converter at the file and assert those counts survive; format twins carry identical numbers so a conversion can be scored exactly.
Related files
- xmlOWASP Dependency-Check Report (XML)The XML twin of the Dependency-Check report — the form most Maven and Jenkins integrations consume — carrying the same four SAMPLE findings inside a namespaced analysis element. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
- xmlCoverage — Clover XMLThe 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.
- xmlCoverage — Cobertura at Zero CoverageA 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.
- xmlCoverage — Cobertura Condition-Coverage AttributesCobertura 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.
- xmlCoverage — Cobertura with One Package per DirectoryThe 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.
- xmlCoverage — Cobertura with Several Source RootsThree <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.
Generated by generation/testing.py. Free for any use, no attribution required — license.