From e8b55f5c58d1d9e5d5cd5b24d96b7d3b51047440 Mon Sep 17 00:00:00 2001 From: =?utf8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?= Date: Sun, 25 Jul 2010 19:52:45 +0000 Subject: [PATCH] t/README: Add a note about the dangers of coverage chasing MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 Signed-off-by: Ævar Arnfjörð Bjarmason Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano --- t/README | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/t/README b/t/README index 468876de0..e49534a1b 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