I've stopped pursuing 'peak code coverage'.
That drive to achieve “almost” 100% in every project — from unit tests to integration tests — never really assured me of quality.
Instead, it became a chase for a number that often missed the point.
And from talking to other senior developers, they feel the same.
Code coverage is important, of course.
It's essential for ensuring reliability and reducing bugs in software. But there's a cost when it becomes an obsession.
Software development isn't just about metrics. It's about crafting solutions. At its core are problem-solving, innovation, and usability, not just numbers.
This is what led me to rethink my approach.
I wanted to step back and define quality in different terms. To stop obsessing over percentages. To forever avoid the mindset of testing for the sake of testing.
I want to create software that works, embraces real-world complexities, and provides value to users.
I want to focus on meaningful tests, solve critical issues.
I don’t want to dismiss code coverage. I want to contextualize it.
It's important to focus on what really matters — functionality, user experience, and overall impact — rather than just achieving arbitrary metrics.
That's the essence of thoughtful software development.
It's not about how many lines of code are tested, but the robustness of our software, the satisfaction of our users, and the real-world problems we solve.
That's a vision of code quality I can get behind.
Can you?
Best, Jarek | 