Manual coverage heatmap review

The problem

The project coverage report says 74 percent. Fine. But 74 percent of what? You still need to know whether the weak spots sit in packages that half the system depends on or in code with a much smaller internal consumer surface. A project-wide percentage hides that difference.

Why it matters

Line coverage shows where the loaded tests exercised code. Fan-in shows how many internal packages structurally depend on each package. Put them together and a weakly covered package with fifteen dependents carries a wider internal consumer surface than a similar gap with one dependent. This workflow deliberately gives you that consumer-blast-radius shortlist. Entry points, adapters, and business-critical leaves remain a separate importance review.

Where to start

Begin with the Topology Graph with the coverage heatmap enabled.

Step by step

1. Load a coverage report.

   Load JaCoCo XML for a Java or Kotlin analysis, or LCOV after a TypeScript graph is loaded. AtlasArc associates matching coverage with the current architecture model. Use a report with branch records when you also want Branch Coverage.

2. Start with the load-bearing shortlist.

   Start exploring opens the Topology Graph, enables Line Coverage, keeps packages at or above the current 75th-percentile Fan-in, and turns on Hide isolated. When that percentile is zero, AtlasArc uses Fan-in 1 so every candidate has at least one internal consumer. Existing deliberate graph filters, your current Root, and Exclusions stay in place.

3. Enable the line coverage heatmap.

   Low line coverage appears red, the middle moves through amber, and stronger coverage moves toward green. Start with red packages that still carry many incoming dependencies. Those are the coverage gaps with the widest internal consumer blast radius.

4. Switch to branch coverage for a second pass.

   When the report contains branch records, apply the Branch Coverage heatmap. It exposes decision alternatives that line execution alone does not distinguish.

5. See whether the gaps cluster.

   For a large module or Root, switch to Composition with the same coverage heatmap. The hierarchy makes it easier to see whether several low-coverage packages sit inside the same branch of the system.

Interpreting results

Coverage in architectural context gives you a practical testing shortlist. Compare coverage colour with incoming dependency pressure and inspect the strongest combinations first. The result is not a universal business-risk ranking. It is the packages where weak coverage meets the widest internal consumer blast radius. Review important entry points, adapters, and low-Fan-in business capabilities on their own terms rather than treating them as safe by default.

Export & share

Use Export → Snapshot as PNG with the Line Coverage heatmap active. It captures the consumer-backed Topology shortlist in dependency context, which is far more useful for planning test investment than a project-wide percentage alone. Snapshot the Composition follow-up when the hierarchy reveals a larger cluster of related gaps.