Minimum Rcov

Uncle Bob, has stated that all code should be 100% covered, but 100% is an asymptote.  Therefore he expects something less then 100%.  This might be true in the Java, or C version of Rcov, but not for Ruby Rcov.  Also, I personally think that 100% is a bit low.

All 100% coverage means is that at least one test touches every line.  And in truly simple code that is usually enough.  But I work on systems, not simple code.  Rarely do I write single use code.  In most cases I write code that does one thing well, but is used by a lot of different part of the system.

Errors are very rarely in core modules, but rather in the runtime combination of core modules.  This is covered by integration testing which is not usually pulled into rcov.  I think this is a mistake.

The following is how I think about a minimum level of Rcov:

1. Exclude libraries from rcov metrics. That is unless you decide to include their unit testing within your own.  Either way this will give you a more accurate reading of coverage.  Seeing rcov at 90%, but thinking it is 100% because rcov can't see libraries isn't a valid assumption, IMHO.
2. Include integration testing in rcov.  Rcov has an option to aggregate several runs into a final number.  You should include both unit and integration testing in the final number.
3. Expect greater then 100% coverage.  Actually, including edge cases, positive, and negative testing the number will be closer to 1000% percent covered.  You read that right, every line of code should be covered by at least 10 tests.
4. Include the rcov threshold test in CI.  You should, before committing, always run all unit tests, integration tests, and rcov threshold.  At first set the threshold low (about 80%) and move it to 100% ASAP.  And by including threshold test in CI then the code can't go out the door without the correct amount of coverage.
5. Review tests first and last.  If your teams doesn't already do code reviews, it should.  If it does then start with the tests and then review the code.  This lets you ensure the obvious edge cases are covered without being swayed by the code.  After reviewing the code re-review the tests to ensure there are no new edge cases need to be covered.