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.
{
"/builds/novus/checkout-service/src/cart/pricing.js": {
"path": "/builds/novus/checkout-service/src/cart/pricing.js",
"statementMap": {
"0": {
"start": {
"line": 2,
"column": 2
},
"end": {
"line": 2,
"column": 42
}
},
"1": {
"start": {
"line": 3,
"column": 2
},
"end": {
"line": 3,
"column": 42
}
},
"2": {
"start": {
"line": 4,
"column": 2
},
"end": {
"line": 4,
"column": 42
}
},
"3": {
"start": {
"line": 5,
"column": 2
},
"end": {
"line": 5,
"column": 42
}
},
"4": {
"start": {
"line": 6,
"column": 2
},
"end": {Specifications
- Seed
- 61200
- Source Files
- 4
- Lines Found
- 140
- Lines Hit
- 127
- Line Pct
- 90.71
- Branches Found
- 24
- Branches Hit
- 17
- Branch Pct
- 70.83
- Functions Found
- 20
- Functions Hit
- 18
- Line Endings
- LF
- Format
- Istanbul coverage-final.json
- Statement Map Entries
- 140
- Fn Map Entries
- 20
- Branch Map Entries
- 12
- Keyed By
- absolute source path
Testing contract
Expected to pass- Scenario
- Flatten Istanbul's per-branch-point arrays into individual branch outcomes.
- Expected result
- The 12 branchMap entries flatten to 24 outcomes of which 17 were taken, matching the BRF/BRH counters in the LCOV twin.
What is a .json file?
JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format representing objects, arrays, strings, numbers, booleans, and null. It is language-independent, human-readable, and the dominant format for web APIs and configuration. It requires a single well-formed root value.
How to use this file
Use an example JSON file to test parsers and serializers, schema validation, Unicode and number-precision handling, and API request or response processing.
How to use this file for testing
“Coverage — Istanbul coverage-final.json” is a deterministic Novus Examples fixture for JSON parsing, Conversion testing, Code parsing. Flat, deeply nested, JSON Lines, and intentionally invalid JSON for testing parsers and error handling.
Documented properties for this file: seed 61200 · LF · Istanbul coverage-final.json. 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.
Feed the file to your parser and assert it handles the documented quirks — quoted delimiters, embedded newlines, ragged rows, or invalid syntax; the valid↔invalid distinction is labelled in the title.
Code examples
import json
with open("istanbul-coverage-final.json") as f:
data = json.load(f)
print(type(data), len(data))Related files
- 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.
- lcovCoverage — 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.
- lcovCoverage — 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.
Generated by generation/testing.py. Free for any use, no attribution required — license.