Complex code with weak coverage
The problem
A complex package can look manageable in isolation, and a coverage report can look acceptable in aggregate. The warning sign appears when one package contains a strong complexity contributor, carries weak branch coverage overall, and is large enough that changing it is not a local edit. That overlap gives you a sharp shortlist for safer refactoring.
Why it matters
CC max points to the strongest complexity contributor inside a package. Branch coverage tells you how much of the package's branching the tests exercise. Put them together and you can find packages where complex code and weak coverage coexist, then open the candidate and check exactly where the testing gap sits. Continue that shortlist in Galaxy to add incoming reach and nearby dependency routes without losing the coverage question. When its metrics are available, Maintenance abyss offers a separate reading of size, complexity, reach, Distance, and line coverage.
Where to start
Begin with Hotspots with the CC vs Coverage preset.
Step by step
- Make coverage and complexity available.
For Java or Kotlin, build the project and load a JaCoCo XML report. For TypeScript, generate the dependency graph with compatible ESLint/SonarJS SARIF complexity data, analyze that source, then load LCOV with branch records. AtlasArc keeps missing evidence unavailable rather than treating it as zero.
- Open Hotspots and select CC vs Coverage.
Start exploring clears stale graph filters and opens Packages, Recursive, Map, and the CC vs Coverage preset. The X axis is CC max, the Y axis is branch coverage, bubble size is lines of code, and colour is CC max. Your current Root and deliberate Exclusions stay in place.
- Find high-complexity, low-coverage packages.
Look for large bubbles with high CC max and weak branch coverage. These are packages where a strong complexity contributor and weak package-level coverage coexist, which is enough to put them on your inspection shortlist.
- Continue the same shortlist in Galaxy.
Switch to Galaxy without choosing a named Galaxy preset. AtlasArc preserves CC max on X, branch coverage on Y, LOC as size, and CC max as colour, then adds Fan-in as depth with high values brought forward. Routes reveal which nearby package candidates actually depend on one another. You keep the coverage question and gain architectural reach.
- Reframe with Maintenance abyss when it fits.
When Distance and line coverage are available, choose Galaxy Maintenance abyss for a separate structural reading. LOC and CC max position the packages, Fan-in controls size, Distance controls colour, and stronger line coverage recedes into depth. Read this as a fresh question, not as a replot of branch coverage.
- Prioritize by size and architectural importance.
Use bubble size to avoid spending the first pass on tiny packages. If two packages have similar complexity and coverage, start with the larger one or the one that is also important in the graph workflows.
- Add characterization tests before refactoring.
Open the package Metrics and inspect its top CC contributor alongside the source and coverage evidence. Add tests around the actual uncovered behavior before simplifying the complex code.
Interpreting results
The points worth opening first are not simply the most complex or the least covered. They are the packages where high CC max, weak package-level branch coverage, and meaningful size coincide. Treat Map as a shortlist, then use its Galaxy continuation to see which candidates also carry incoming reach or depend on one another. Check the top complexity contributor against source and coverage evidence before deciding where tests belong. Maintenance abyss is optional and asks a different question about size, complexity, incoming reach, Distance, and line coverage.
Export & share
Export the CC vs Coverage Map as PNG for the clearest package shortlist. Export its Galaxy continuation when Fan-in depth and route context help explain why a candidate deserves attention. If you explicitly reframe with Maintenance abyss, label that image as a different structural reading.