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.
{
"total": {
"lines": {
"total": 140,
"covered": 127,
"skipped": 0,
"pct": 90.71
},
"statements": {
"total": 140,
"covered": 127,
"skipped": 0,
"pct": 90.71
},
"functions": {
"total": 20,
"covered": 18,
"skipped": 0,
"pct": 90.0
},
"branches": {
"total": 24,
"covered": 17,
"skipped": 0,
"pct": 70.83
}
},
"/builds/novus/checkout-service/src/cart/pricing.js": {
"lines": {
"total": 44,
"covered": 40,
"skipped": 0,
"pct": 90.91
},
"statements": {
"total": 44,
"covered": 40,
"skipped": 0,
"pct": 90.91
},
"functions": {
"total": 6,
"covered": 5,
"skipped": 0,
"pct": 83.33
},
"branches": {
"total": 8,
"covered": 6,
"skipped": 0,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 json-summary
- Has Total Key
- true
- Per File Keys
- 4
- Statements Mirror Lines
- true
Testing contract
Expected to pass- Scenario
- Read an overall coverage percentage from an Istanbul summary document.
- Expected result
- total.lines.pct is 90.71 and equals 127/140 recomputed from the counts.
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 JSON Summary” is a deterministic Novus Examples fixture for JSON parsing, Conversion testing, Schema validation. Flat, deeply nested, JSON Lines, and intentionally invalid JSON for testing parsers and error handling.
Documented properties for this file: seed 61200 · LF · Istanbul json-summary. 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("coverage-summary.json") as f:
data = json.load(f)
print(type(data), len(data))Related files
- jsonCucumber JSON — Passing Checkout ReportThe 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 most common unit bug when converting between the two.
- ndjsonCucumber Messages — Passing Checkout Run (NDJSON)The machine twin of checkout.feature: the cucumber-messages envelope stream a runner emits, with meta, source, gherkinDocument, one pickle per expanded scenario, and paired testStepStarted/testStepFinished envelopes carrying nanosecond durations. Written as NDJSON because that is the format's actual wire shape — one envelope per line, not a JSON array.
- jsonAttestation With a Full SPDX PredicateAn in-toto statement whose predicate is an entire SPDX 2.3 document — the nesting that makes attestation payloads large and that a size-limited verifier has to cope with. Every package, version, hash and licence is fictional — the tree describes nothing real.
- jsoncargo-audit Report (JSON)A cargo-audit report that shows three findings while a fourth is on the ignore list, plus an unmaintained-crate warning — so a gate must decide whether warnings count against it. 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.
- jsonCSAF 2.0 VEX DocumentA CSAF 2.0 VEX advisory with the nested product tree that CSAF requires — vendor, product name, product version — and product_status buckets rather than a per-statement status field. 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.
- jsonCycloneDX 1.5 Application SBOM (JSON)A CycloneDX 1.5 SBOM of the same fictional tree, useful for spec-version migration tests: 1.5 introduced the object form of metadata.tools and this file uses it, while dropping the 1.6-only external references. Every package, version, hash and licence is fictional — the tree describes nothing real.
Generated by generation/testing.py. Free for any use, no attribution required — license.