At the current company I work for, within our repositories we have a rule that we need to achieve 100% code coverage for the work that we commit and all code that we extend. Although this seems like good practice in theory, it leads to unthoughtful test creation in practice which is an anti-pattern. The tests that we have in our repository are so mocked, that they don’t actually provide much useful coverage as they are intended to.
Martin Fowler’s Article on Test Coverage really thoughtfully laid out these insights and reminded me that even if you are practicing Test Driven Development (TDD), having a requirement for 100% test coverage might not be the best approach to achieve the goal of having quality coverage.
At the end of the day, coverage should be used as a tool to understand where there are gaps in your code coverage and where issues might arise in production, not as a tool to block code from being pushed out.
Linked Map of Contexts