t/README: Add a note about the dangers of coverage chasing
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> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ævar Arnfjörð Bjarmason committed
Jul 25, 2010 at 19:52 UTC
e8b55f5c58d1d9e5d5cd5b24d96b7d3b51047440
1 file changed
+9
t/README
+9
@@ -271,6 +271,15 @@ Do:
271
- Check the test coverage for your tests. See the "Test coverage"
272
below.
273
274
+ Don't blindly follow test coverage metrics, they're a good way to
275
+ spot if you've missed something. If a new function you added
276
+ doesn't have any coverage you're probably doing something wrong,
277
+ but having 100% coverage doesn't necessarily mean that you tested
278
+ everything.
279
+
280
+ Tests that are likely to smoke out future regressions are better
281
+ than tests that just inflate the coverage metrics.
282
+
283
Don't:
284
285
- exit() within a <script> part.