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."
git diffs can definitely help with newer bugs or if you can show that it's a regression (didn't error before commit 1234abcd but did after).
An intersection between code coverage and a git diff once answered that handily for me.
Jtsummers•9mo ago
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.