Why reaching 100% code coverage must NOT be your testing goal
-
Kent Sharkey wrote:
Great teams don’t. Why?
Because it's kinda silly to test getters and setters and such?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
Code coverage is like trying to get to the speed of light. The more code coverage you have, the more massive your code. At some point, the energy required to go the next 0.00001% of coverage becomes impossible because the mass of code is so close to infinite. ;P Not to mention the whole time dilation effect, where your tests are obsoleting faster and faster as other coders make changes. Something like that. :laugh:
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity Framework -
Code coverage is like trying to get to the speed of light. The more code coverage you have, the more massive your code. At some point, the energy required to go the next 0.00001% of coverage becomes impossible because the mass of code is so close to infinite. ;P Not to mention the whole time dilation effect, where your tests are obsoleting faster and faster as other coders make changes. Something like that. :laugh:
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity FrameworkOK, I get your point. But then, testing shouldn't go by the code lines, but what those code lines do. There should be no reason to change/update a test because the code is changed - only when what the code is supposed to do changes. Tests should be developed and implemented by people who know nothing of the code. They should make tests for all the functionality, regardless of the lines of code to implement it. If some code is not run during a complete test, it either indicates that the code is dead and can be removed, or that there is some functionality that the test developers never were told about. Maybe the developer didn't tell anybody about this functionality - which is really bad. Secret, undocumented, untested functionality is bad for any software. So don't strive for 100% code coverage. Strive for 100% functionality coverage. If that doesn't lead to 100% code coverage, you should take a close look at the code and ask: What the elephant is that code there for?
Religious freedom is the freedom to say that two plus two make five.