You can't have 100% test coverage with these kinds of bugs, because these bugs create unreachable expressions.

You can either find out you have these bugs from lint errors or you can find out by finding them in code coverage reports while chasing 100% code coverage. Most people would obviously prefer the former.

Neither would malloc(), and yet we still like Rust's borrow checker.

I've never seen a project with 100% condition tests coverage. Sure, they exist, but they're as rare as unicorns.

Maybe sqlite3: https://www.sqlite.org/testing.html.

I considered mentioning it, but to my previous understanding sqlite measures coverage at the assembly level and not at the C level. Skimming the link, it seems I was wrong, so thanks, TIL. My previous conception doesn't make much sense, now that I think of it.

Ironically, that's a fantastic example of just how unachievable full test coverage actually is in most projects.

> By comparison, the project has 590 times as much test code [as program code].

I think you’re technically correct. But if you are someone who is writing 100% branch coverage code this rule could still be useful. It will quickly point out parts of your code base that are going be impossible to test with 100% coverage.

100% coverage is very rare outside safety critical code. People are much more willing to invest time in adding features than writing (often boring, repetitive and tedious) tests just to get perfect coverage -- finding a bug later is a risk people are willing to take.

And even 100% doesn't mean much -- you can easily come up with examples where you have 100% coverage but there are still bugs.

100% branch coverage, which is even more rare. I've done it for a couple of projects, and it's really useful (there were bugs hidden even in the last few percent), but it is a decent amount of work.