I think a part of the difficulty is in the language of coverage. "100% test coverage" usually means statement coverage due to the nature of popular tooling. I

I think a part of the difficulty is in the language of coverage. "100% test coverage" usually means statement coverage due to the nature of popular tooling. If you deeply care about correctness you are usually more interested in path coverage which is more tied to things like heap shape or state space... (which depending on your system design might encompass stuff in your database). Also yeah, technically the exceptions which can be thrown at each point in your software if you work in a language with those. Unfortunately there's not much tooling for that so it's not visible in the same way as the more naive metrics. Anway my point is that you can waste time pushing for "100% statement coverage" measurable by naive tools but still not exercise important paths, which I think is your point.