Getting 100% code coverage doesn't eliminate bugs
-
Code Pipes[^]:
TL;DR - Getting 100% coverage on a project doesn’t mean you have zero bugs. Here is an extreme example to prove it.
In related news: duh
-
Code Pipes[^]:
TL;DR - Getting 100% coverage on a project doesn’t mean you have zero bugs. Here is an extreme example to prove it.
In related news: duh
Article wrote:
Getting 100% coverage on a project doesn’t mean you have zero bugs.
There is no bug free code. You just have to wait until the correct one comes to check / use it (either a smart hacker or the dumbest available user)
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Code Pipes[^]:
TL;DR - Getting 100% coverage on a project doesn’t mean you have zero bugs. Here is an extreme example to prove it.
In related news: duh
Of course not. Because users are idiots. :laugh:
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity Framework -
Code Pipes[^]:
TL;DR - Getting 100% coverage on a project doesn’t mean you have zero bugs. Here is an extreme example to prove it.
In related news: duh
I think it's really more that you cover or don't but with INTENT across 100%. It's not so much that you literally cover 100%. So something like typical MSFT webapi... It's fine to just chuck a bunch of that all into the same bucket where it's going to be a bug in a black box or a bug in the way you're interfacing with it. The reason you do coverage isn't so much about bug elimination by a misguided notion that bug count has an inverse relation to coverage %. Rather, it's about WHEN a bug happens, rapidly reproducing it, precise identification of its source, knowing right where to correct for it, and authoring a new test which would have found it before it went live.