April 25th, 2025

Differential Coverage for Debugging

Differential coverage is a debugging technique that compares code coverage of passing and failing tests to identify problematic code, helping developers focus on specific issues in large codebases.

Read original articleLink Icon
Differential Coverage for Debugging

The article discusses a debugging technique known as differential coverage, which helps identify problematic code by comparing the code coverage of passing tests with that of a failing test. The author illustrates this method using a specific example from the Go programming language, where a bug was introduced into the `math/big` package. By collecting coverage profiles from both passing and failing tests, the author demonstrates how to create a differential profile that highlights the unique lines of code executed during the failing test. This approach allows developers to focus on specific code blocks that may be causing the failure. The author notes that while differential coverage is a valuable tool, it is not infallible, as passing tests can still execute buggy code under certain conditions. The article concludes by emphasizing the efficiency of differential coverage in narrowing down potential issues in large codebases and suggests that it can also be applied to passing tests to explore specific functionalities.

- Differential coverage compares code coverage between passing and failing tests to identify problematic code.

- The technique can save time by pinpointing specific code blocks that may be causing test failures.

- It is not foolproof, as passing tests can still execute buggy code under certain conditions.

- The method is efficient for large codebases, helping developers focus their debugging efforts.

- Differential coverage can also be applied to passing tests to investigate specific functionalities.

Link Icon 4 comments
By @Jtsummers - about 12 hours
https://www.debuggingbook.org/html/StatisticalDebugger.html

A related method. Not quite as straightforward as running with and without the failing test and comparing coverage reports. This technique goes through and collects many test runs and identifies lines only associated with or most often associated with failing runs.

By @ossusermivami - about 1 hour
what about just doing a git diff ? that would see the method was not called before?
By @drewcoo - about 12 hours
I had no idea this had (or was worthy of) a name.

That's the whole point of coverage diffs.

The tough ones are the tests that sometimes fail and give you the same coverage results - the problem is not in the code under test! And the lazy/common things to do are re-run the test or add a sleep to make things "work."