This note serves mostly to stand vigil against project requirements for 100% coverage, which I've seen a few clueless leads or managers attempt to implement for

This note serves mostly to stand vigil against project requirements for 100% coverage, which I've seen a few clueless leads or managers attempt to implement for teams. 100% code coverage as a requirement is usually a waste of time and resources. Test code, especially units, at their edges. This frees you to change implementation details while preserving functionality. In two decades of experience, the best codebases I've worked on have around 50-80% coverage in unit tests. 100% is a false sense of security as bugs still present themselves to users. I've also seen devs burn days of effort chasing code coverage metrics, days of nearly zero-value add to the quality of the project. I completely agree that "good test coverage" is critical; I've just not seen that it extends to 100%. Pre-commit hooks for linting and formatting and automatic test runs are all best practices. Dog fooding does some amazing things in terms of usability.