search

Check Test Coverage

Line coverage is a vanity metric. A function can be "covered" by a test that never checks its output. What matters: which high-complexity, high-exposure functions have no tests at all? Pharaoh answers that question per module, ranked by risk.

hashtag
The workflow

hashtag
1. Find the coverage gaps

Ask your AI tool:

Which modules have the worst test coverage?

This triggers get_test_coverage. You get back per-module summaries:

  • Files with associated test files

  • Files without any test coverage

  • High-complexity functions that lack tests - the most dangerous gaps

hashtag
2. Rank gaps by risk

Ask your AI tool:

What's the regression risk in the payment module?

This triggers get_regression_risk. Each function gets scored by:

  • Complexity - cyclomatic complexity (branches, loops, conditionals)

  • Caller count - how many other functions depend on it

  • Churn - how frequently it's been modified

  • Exposure - whether it's connected to HTTP endpoints, cron jobs, or CLI commands

The intersection of "high regression risk" and "no tests" is where production bugs live.

hashtag
3. Trace downstream impact

Ask your AI tool:

This triggers get_blast_radius on the checkout module. Combine the result with coverage data: if a function has 12 downstream callers and no tests, that's your top priority.

hashtag
What to look for

  • High complexity + no tests - a function with cyclomatic complexity above 10 and zero test files is a ticking time bomb. Every branch in that function is an untested path to production.

  • High regression risk + no tests - the intersection of "likely to break" and "no safety net." These functions should be at the top of every test-writing sprint.

  • Modules with 0% coverage - often utility modules or internal services that were "too simple to test." They stay simple until they don't, and by then nobody remembers what they're supposed to do.

  • High-exposure functions - functions connected to multiple HTTP endpoints or called by many modules. A bug here affects the most users.

hashtag
Tips

  • Prioritize test writing by regression risk score, not by module name alphabetically. A risk-ranked backlog ensures you write the most valuable tests first.

  • High-complexity functions usually need integration tests, not unit tests. Mocking the 8 dependencies of a complex function hides the interaction bugs that matter most. Test the real code path.

  • Check coverage after every PR. Catching test gaps at review time costs minutes. Catching them after a production incident costs hours or days.

PreviousFind Dead CodeNextMap Open-Source Repos

Last updated