Line and branch coverage
Also known as: line coverage · branch coverage · JaCoCo coverage · LCOV coverage
What it is
Line coverage is the ratio of executed source lines to total source lines in a matching package, class, source folder, or source file. Branch coverage is the ratio of executed control-flow branches to total branches. AtlasArc reads JaCoCo XML for Java and Kotlin or LCOV for TypeScript, attaches matching coverage at the granularities supported by the current model, then surfaces it as heatmap overlays on the architecture view so test gaps appear in architectural context rather than in an isolated coverage tool.
Why it matters
Coverage numbers in isolation are often too high-level to act on. A project-level line coverage of 70% tells you the overall result, but not where the weak spots sit. AtlasArc maps coverage to the package graph: low line coverage combined with high Fan-in exposes packages where weak test execution meets a wide internal consumer surface. Low branch coverage combined with high Fan-out exposes untested decision alternatives in packages that cross many outward dependency seams. Coverage in architectural context is coverage you can actually act on.
What a high value usually means
High line coverage means most executable lines in the package were executed at least once during the reported test run. High branch coverage means most recorded decision alternatives were exercised. Both give you a broader automated safety net for change. High coverage still does not mean the tests are good; they may assert little or test incidental behavior.
What a low value usually means
Low line or branch coverage means the reported test run did not execute significant lines or decision alternatives in the package. Combine low coverage with high Fan-in when you want the gaps with the widest internal consumer blast radius. A low-Fan-in entry point, adapter, or business-critical package may still matter greatly; it belongs to a different importance review. Instability describes the balance of outgoing to total structural coupling, not how often the package changes, so it does not provide observed change-frequency evidence for coverage risk.
When not to overinterpret it
Coverage metrics require a compatible report to be loaded in AtlasArc. If no report or matching record is available, coverage fields show no value rather than zero. An LCOV report without branch records keeps Branch Coverage unavailable. The metrics reflect the specific test run that produced the report. Coverage also does not measure test quality: a package can have 100 percent line coverage from a test that asserts nothing. Treat coverage as a risk indicator for untested paths, not a badge of test quality.
Where AtlasArc shows it
As heatmap colour overlays on the Topology Graph, Package Matrix, and Composition view, available in the heatmap metric selector once a compatible report is loaded. In the Metrics sidebar when a matching package, class, source folder, or source file is selected, if matching report data has been loaded.
How AtlasArc computes it
Line coverage = covered lines / total lines. Branch coverage = covered branches / total branches. AtlasArc reads those counters from a JaCoCo XML report for Java and Kotlin or an LCOV report for TypeScript. It does not run tests or generate the report itself.