Your 87% coverage number is a lie of omission, and the omitted part is exactly where production incidents live. Coverage tools measure the lines tests bother to touch, not the lines that are reachable and dangerous.
I ran into this directly on a payments service a few months ago. The suite was sitting at 84% line coverage, the team was proud of it, and we had a silent data-loss bug in the retry exhaustion path that had been shipping for eleven months. The test that was supposed to cover retries existed. It called the function. It never actually pushed the retry counter past the threshold that triggered the fallback write, so the fallback write's error handler had never executed under test in the history of the codebase. Line coverage counted the function as covered because the happy path went through it. The shadow path never ran.
That gap has a name worth using precisely: shadow coverage. It is the delta between what your static call graph says is reachable from your test entry points and what your runtime coverage traces say actually executed. Standard tooling collapses that delta to zero by ignoring it entirely.
The mechanics of why this happens are worth being specific about. lcov, coverage.py, Istanbul, JaCoCo: they all instrument at the same level. A line is covered if any test causes execution to reach it. A branch is covered if both sides of a conditional are taken at least once across the entire suite. Neither tool penalizes you for the branches that exist but that no test ever pushes into. They report the ratio of covered-to-reached, not covered-to-reachable. Those are different denominators.
Static call graph analysis gives you the second denominator. Tools like pyan, codeql, or even a straightforward AST walk over your codebase can enumerate every function, every branch point, and every reachable callsite from a set of roots. When you diff that graph against your runtime coverage trace, you get a list of nodes the tests never visited. That list is your shadow surface.
Here is a minimal version of what that diffing step looks like in practice:
import json
def load_coverage_trace(coverage_json_path):
with open(coverage_json_path) as f:
data = json.load(f)
executed = set()
for file, meta in data["files"].items():
for line, count in meta["executed_lines"].items():
if count > 0:
executed.add((file, int(line)))
return executed
def load_reachable_nodes(call_graph_path):
with open(call_graph_path) as f:
data = json.load(f)
# Each node: {"file": str, "line": int, "fn": str}
return {(n["file"], n["line"]) for n in data["nodes"]}
def shadow_surface(coverage_json_path, call_graph_path):
executed = load_coverage_trace(coverage_json_path)
reachable = load_reachable_nodes(call_graph_path)
return reachable - executed # nodes reachable but never executed
if __name__ == "__main__":
shadow = shadow_surface("coverage.json", "callgraph.json")
print(f"{len(shadow)} reachable nodes never executed by any test")
for file, line in sorted(shadow)[:20]:
print(f" {file}:{line}")
This is not production-ready, but the concept is exact: build the reachable set from static analysis, subtract the executed set from your coverage tool, and treat the remainder as your risk surface. The call graph needs to be rooted at your actual test entry points, not your whole application, otherwise you pull in CLI paths and admin tooling that genuinely should not be covered by unit tests. That scoping decision matters. It is the part most teams get wrong when they first attempt this.
The nodes that cluster in that shadow surface are almost never in the happy path. They are the except blocks that only trigger on network partition. The fallback cache write that fires when the primary store is unavailable. The retry exhaustion handler. The feature flag fork that was added two years ago for a rollout that completed, with the old branch still sitting there. These are the highest-risk lines in any production system because they are precisely the lines you need when something is already going wrong, and they are the lines most likely to have their own bugs because they are never exercised under normal conditions.
The argument I want to make is specific: chasing a higher line coverage percentage is the wrong optimization once you are past the first 70%. Raising coverage from 84% to 91% by writing easier tests of simpler paths gives you worse signal than finding and exercising the top 50 shadow nodes in your call graph. The 91% number is a better average over the code your tests already reach. The shadow analysis tells you about the code they do not reach at all.
That delta deserves to be a first-class CI gate, not an afterthought.
This means treating shadow surface size as a metric you track and gate on, not just report. If a PR increases the number of reachable-but-unexercised nodes, that is a failing check. If it decreases the shadow surface without lowering any coverage thresholds, that is a green signal worth rewarding. The tooling to implement this exists today: CodeQL can generate call graphs, coverage.py --json gives you the runtime trace, and the diff is arithmetic. What most pipelines are missing is the integration step that computes and gates on the delta.
OpenThunder does this combination natively, running static call graph analysis alongside runtime coverage traces and surfacing the delta as a structured finding rather than asking you to wire three tools together by hand. If you want to see what that looks like against your own codebase, the analysis runs in your existing CI environment without requiring instrumentation changes.
Dead code detection is a related but distinct problem. Shadow paths are reachable; dead code is not. Both matter, but they require different tooling and have different risk profiles. A dead code branch cannot execute in production, so it cannot cause a runtime failure, though it adds maintenance surface. A shadow path can absolutely execute in production, specifically under the conditions that are already stressful, and it will do so without ever having been verified. That asymmetry is why shadow coverage is the higher-priority problem.
One concrete recommendation: take your current call graph, root it at your test suite entry points, diff it against your last coverage run, sort the shadow nodes by how recently the surrounding file was modified, and look at the top ten. I would bet that at least three of them are error-handling paths with logic that has never been tested end-to-end. That list is where your next test sprint should start, not wherever your coverage report shows an uncovered branch in a utility function.
The coverage number your CI reports is a statement about the code your tests happen to reach. It says nothing about the code they skip.
Put a verification gate on your pipeline
If you want to stop tracking shadow coverage manually, OpenThunder runs static, dynamic, and behavioral checks on every change and turns failures into fixable findings, including the delta between your reachable call graph and your runtime trace. Try it here.
The real risk surface in any mature codebase is not the code with low coverage, it is the code your suite never counted against itself at all.