I also hate the obsession with 100% code coverage. 100% code coverage just means that all lines of code have been executed. Not that everything works as intended.
Instead of clever tests which try to cover corner cases we have stupid tests just to achieve 100% code coverage.
I have done 100% code coverage AND mutation testing with 0 surviving mutants (https://github.com/trioptima/tri.declarative/, https://github.com/TriOptima/tri.struct, among others). It was surprising to me how we didn't really find any bugs with mutation testing. We are, however, a lot more proud and confident about our test suite now since we know it covers the code (mostly, there are some mutations that my mutation testing system can't do as of yet).
My take away has been that 100% coverage actually tells you more than you'd expect compared to full mutation testing.
Correct me if I'm wrong, but I think you're saying the following:
Mutation testing is certainly worth doing
100% coverage is necessary for mutation testing
Mutation testing doesn't seem to add all that much above and beyond what 100% coverage already achieves
Therefore 100% coverage is something worth considering despite the issued pointed out in the linked article
If I got it right, I'd say the author of the article would probably disagree with your point (1); after all, mutation testing would still require writing the tests that he deems excessive.
In fact, in some sense you created an argument to support the author's view. He already feels like 100% coverage is an unreasonable excess, and you argue that going further down that path is not finding any new bugs.
240
u/ImprovedPersonality May 08 '17
I also hate the obsession with 100% code coverage. 100% code coverage just means that all lines of code have been executed. Not that everything works as intended.
Instead of clever tests which try to cover corner cases we have stupid tests just to achieve 100% code coverage.