I'd never thought about this before, but you can definitely flip this around to a pathological case of doing the opposite of striving for 100% coverage. The pr

I'd never thought about this before, but you can definitely flip this around to a pathological case of doing the opposite of striving for 100% coverage. The problem with 100% coverage that I think of is that the last 30% is often boilerplate code (generated getters/setters in Java and that kind of thing). But what if an engineer started with the boilerplate and only then progressed to tests that are actually important? You might get to 30% without testing anything useful at all. Then you might test half of the important stuff and hit an arbitrary metric of 70%. If someone were ruled by the sonarqube score, they might even do this. Yeah, thinking about the why matters more than the %.