[PATCH v3 7/7] t/README: Add a note about the dangers of coverage chasing
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jul 25, 2010, 19:52 UTC
- Message-ID
- <1280087565-24671-8-git-send-email-avarab@gmail.com>
- In-Reply-To
- <1280087565-24671-1-git-send-email-avarab@gmail.com>
Having no coverage at all is almost always a bad sign, but trying to attain 100% coverage everywhere is usually a waste of time. Add a paragraph to explain this to future test writers.
Inspired-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> ---
Jonathan doesn't particularly like this one. I have no particular preference, just trying to get across the point that you shouldn't cargo-cult-coverage.
t/README | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README index 15d4b52..4fe8d50 100644 --- a/t/README +++ b/t/README @@ -271,6 +271,15 @@ Do: - Check the test coverage for your tests. See the "Test coverage" below. + Don't blindly follow test coverage metrics, they're a good way to + spot if you've missed something. If a new function you added + doesn't have any coverage you're probably doing something wrong, + but having 100% coverage doesn't necessarily mean that you tested + everything. + + Tests that are likely to smoke out future regressions are better + than tests that just inflate the coverage metrics. + Don't: - exit() within a <script> part.
-- 1.7.0.4