[nimblegorilla]

Seems like 50% coverage is better than 0% coverage and 75% coverage is better than 50% coverage.

The author argues about the horrors of going from 80% to 79.9%, but I don't see how that is any different from the suggestion to explicitly exclude code. The excluded code is still in the gray area of code that is included but not covered by tests. What happens when someone starts making breaking changes to excluded code?

[derefr]

> What happens when someone starts making breaking changes to excluded code?

You... don't. You un-exclude it first, and then, because of the rule, you're not allowed to commit the code until you write the tests that bring it back up to 100% coverage. Then you make breaking changes.

[nimblegorilla]

I'm not following the benefit of excluding code in the first place. Your method seems like more work, more error prone, and more likely to leave unintended gaps in coverage.

[wvenable]

Lots of code bases have code coverage in some middle range, lets say it's 82.34%. What does that number tell you? Did the team write 7.64% more code this month that doesn't have test cases?

The point you're making is actually irrelevant to the discussion. If you explicitly excluded code, you probably have a reason for that and you take your chances. Ideally, in a perfect world, you'd have no excluded code.

[AgloeDreams]

This is why we have tools like coveralls.

Also, this method doesn't show when you remove excluded code or add coverage for it. In a perfect world you should have no excluded code, and in a perfect world you should have 100% coverage.

World isn't perfect though, and a good working product with critical features is better than one lacking important features but with '100%' coverage.