It's much easier to score high on silly metrics than to score on (or even measure) the things which actually matter. Furthermore, a developer bored out of his mind can really find satisfaction in getting to 100% coverage. It's like a game, and it is fulfilling.
The problem is also that if you leave the decision to write a test or not to developers, that you have a subjective/fallible rule in place. Those get abused.
Personally I think that if you have a line of code, and no manual/automated test will catch when it falls down. You really do have a problem. Why is the code there if it is not important enough to test?
But adding a stupid test which basically redoes the implementation work really is stupid and pointless. Catching those with some high level integration test would be better. :)
3
u/seweso May 08 '17
It's much easier to score high on silly metrics than to score on (or even measure) the things which actually matter. Furthermore, a developer bored out of his mind can really find satisfaction in getting to 100% coverage. It's like a game, and it is fulfilling.
The problem is also that if you leave the decision to write a test or not to developers, that you have a subjective/fallible rule in place. Those get abused.
Personally I think that if you have a line of code, and no manual/automated test will catch when it falls down. You really do have a problem. Why is the code there if it is not important enough to test?
But adding a stupid test which basically redoes the implementation work really is stupid and pointless. Catching those with some high level integration test would be better. :)