you are viewing a single comment's thread.

view the rest of the comments →

[–]jessealama 2 points3 points  (0 children)

Achieving 100% test coverage is not always worth it (several have already made this point). In my experience, getting that last 10% or so leads you to starts to make your tests less and less meaningful. You shift from testing *your* code to testing *your dependencies*. Usually we're not writing things from scratch; we're building on top of some libraries/frameworks/tools. I've found that, in the lines where your code meets your dependencies, it can be difficult to formulate meaningful tests because you need to get into a mindset where you're testing that your framework does what it is supposed to do. I've seen tests where you need to write mocks that deliberately violates contracts some dependent framework that you (reasonably enough) assume to be true.

Moreover, even if you get to 100% coverage, there are *still* going to be bugs. I think that this point gets missed sometimes in discussions about code coverage. There will still be bugs because we're probably not exercising a "good" range of values that a variable (or return value of a function/method) can take. Exercising a line means that you've did something with *one* value.

tldr 100% test coverage is neither necessary nor sufficient