3 ms·
This is totally ridiculous. Test coverage clearly matters even if it's not 100%, as anyone who has ever worked on an older codebase knows. As long as you're n
by aluminum96 7y ago
This is totally ridiculous.
Test coverage clearly matters even if it's not 100%, as anyone who has ever worked on an older codebase knows.
As long as you're not causing coverage regressions, it is perfectly acceptable to leave untested code that "should" be tested, but hasn't been changed in years.
Test it when you change it; don't test for the sake of achieving a coverage benchmark.
- rightbyte 7y agoAnd implying that there is 100% coverage just because the instruction register had all valid values is silly. When writing test one should worry about the other registers too ...
- DoofusOfDeath 7y agoThank you for stating this so succinctly! This concern has been nagging me in the back of my mind, but I hadn't convinced myself that code-coverage was insufficient (in practice) until you framed it this way. Now all kinds of supporting examples come to mind: - divide-by-0 errors - floating-point exceptions - numeric underflow / overflow (both silent and signaled) The alternative code paths exercised by these situations are generally outside the purview of code-coverage tools, because they reside in the silicon / firmware, process' default signal handlers, etc.
- m4r35n357 7y agoMutation testing can expose weaknesses like these in your automated tests.