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@xxxxxxxxx>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
---
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html