Also, to answer why ever be less than 100% is that it depends. Usually, I prefer writing behavioural & integration tests, over chasing per-line coverage which might give a false confidence.
I'm not saying getting 100% coverage is bad, but with my experience working on several different projects, I've seen that the last 10-20% is usually low-value surface.
For critical modules like auth, money, policies (business-logic), should aim at close to > 95%.
When you reach that 100% mark, in my opinion, you might have to write brittle tests which slows down your refactoring with little risk reduction.
Again, to summarize, it's not a black/white answer on having 100% or no coverage, but this differs from project to project, and generally having anything above 80% that covers the core-business logic of projects tends to work in my opinion.
Also, to answer why ever be less than 100% is that it depends. Usually, I prefer writing behavioural & integration tests, over chasing per-line coverage which might give a false confidence.
I'm not saying getting 100% coverage is bad, but with my experience working on several different projects, I've seen that the last 10-20% is usually low-value surface.
For critical modules like auth, money, policies (business-logic), should aim at close to > 95%.
When you reach that 100% mark, in my opinion, you might have to write brittle tests which slows down your refactoring with little risk reduction.
Again, to summarize, it's not a black/white answer on having 100% or no coverage, but this differs from project to project, and generally having anything above 80% that covers the core-business logic of projects tends to work in my opinion.