Over the past few weeks, we've been restructuring our marketplace. We basically had to rebuild the project from scratch to support new business rules and migrate our database from NoSQL to SQL — all without affecting the production environment experience.
Our CI/CD pipeline includes automated analysis with SonarQube to catch bugs, vulnerabilities, duplicated code, test coverage, and more.
Up to that point — everything’s great!
But then… the pipeline started failing a few times due to unit test coverage falling below the expected 70% threshold.
The problem? The uncovered areas included things like DbContext, repository classes, and even some domain entities — areas that, according to best practices, shouldn't be the main focus of unit testing.
The danger of chasing high test coverage at all costs is that you end up testing things outside of your business logic — like framework behavior, library internals, and implementation details that are likely to change.
✅ Focus on testing what matters: the behavior and rules of your business.
📉 High coverage doesn’t always mean high-quality tests.
Code with purpose. Test with strategy. Deploy with confidence.
👉 Here’s an article where Martin Fowler explains this much better:
https://martinfowler.com/bliki/TestCoverage.html
Top comments (0)