100% Code coverage is useless. Here's why you should aim for it.
First of all, I do believe 100% code coverage is useless. But I think there's a reason to try and achieve it, depending on your individual context.
Just to be clear: As a backend engineer, I do advocate for more component based testing approaches, for instance, mocking third party services with something like WireMock and actually running your code with the support of testcontainers.
In this case though, I really want to talk about unit testing, and how I believe one should aim for that 100% code coverage (at first).
TL;DR
I think you should aim for 100% code coverage if you're a less experienced software engineer because realizing how boring it gets might help you refactor the code you write to be more reliable, easy to test, and easy to maintain.
Experience makes a difference
Let us paint a picture: Two software engineers of different experience levels, engineer A has a couple of years of experience on his back, and has built a plethora of systems from the ground up, as well as managed a bunch of legacy code. Engineer B, on the other hand, has been working as a SWE for a short period, and just found out about how code coverage can help him to make sure his code ships sucessfully to production.
Simply put: Engineer A is pretty good. Enginer B still needs to experience a lot in his career.
Ask yourself: If you reach out to both engineers and say "100% code coverage is useless, and it's not worth your time", which of them do you think will actually understand the reason behind it?
Regardless of the future arguments to be presented, If you're closer to engineer A than to engineer B, you might already be getting my point. Actually putting time to reach that 100% mark for a less experienced engineer means he will have to understand the written code in order to deliver the task, whilst more experienced engineers already have a clear vision of what they are writing as it's being written.
Code Quality 🔗 Testing Ease
Many engineers don't enjoy writing tests just because it can get boring sometimes. Boilerplate tests are indeed boring, and solutions for it should really be considered, but simply ignoring to cover failure scenarios on test because it's boring is unacceptable. After all, I'd say testing branches is more important than actually testing lines of code.
Here's what I think whenever the "testing this is boring" thought comes to mind: If writing tests for an implementation is hard, maybe it is the code being tested that's poorly written.
It turns out to be true most of the time.
This is why I believe trying to achieve full code coverage helps to clean up your code. Maybe you'll be writing tests for a piece of code and suddenly realize some condition on your code is simply unreachable, or it makes you think: why is this even here?
Great! Refactor it, prettier code. 🤌
Conclusion
I hope I've made my point clear about why you should (not religiously) chase that sweet 100% code coverage mark. I've chased that mark in the past, and I'd say that it surely helped me improve my code over time. See? It doesn't mean the code was any better, just that it made me better as a professional.
I decided to write this post after watching a video by the Continuous Delivery youtube channel where Dave Farley makes some very interesting points about the subject. Let that be a recommendation of the channel as well.