Should We Aim For 100% Code Coverage With Automated Tests?

Automated tests are a kind of "invisible guardian" that are not only brilliant, but will also boost your confidence as a developer. When well written, they give you the freedom to make changes to your code without fear. You can add functionalities without breaking anything.

My experience with automated testing

I remember this project where we made major changes to our backend architecture. Without changing them, our high-level tests guided us through the rework. We broke absolutely nothing. No bugs were added to the list that week. It's an indescribable feeling! It's hard to get a project manager to understand how this "invisible guardian" of automated testing really improves your confidence and saves you a lot of time.

I've talked to a number of developers and one subject always stood out: testing. How should I approach them? How can I improve my testing strategy? While these are all very interesting questions, I have to admit that one has really caught my attention recently.

What is the ideal code coverage I should aim for in my automated tests?

Of course, you can simply throw out a number and commit to it. We could aim for perfection with 100% code coverage, just as we could be reasonable and aim for 80% code coverage. In fact, neither answer works for me. 

Even if my software has 100% code coverage, which is almost impossible, I can still blindly make changes and break functionalities. How is this possible if all my software is, theoretically, tested?

Answering the question with a number means we simply don't understand the purpose of automated testing. Why would you want to blindly target a metric? In fact, the real question isn't exactly about metrics. It's about confidence. You shouldn't be aiming for a percentage, but rather a level of confidence. How confident are you about your current system? What would happen if I hired a team of a hundred testers tomorrow to check your system? Would you put your career on the line?

Testing to improve or to reach targets?

The last statement is a little extreme and I dare imagine it will never happen. We humans make mistakes. We do. But you can definitely change your attitude. You need to focus on validating the behavior of your features, not the details of your methods. Testing the internal state of a class doesn't give you the high level of confidence you need to iterate quickly. In fact, aiming for a percentage will lead you to create "false tests" simply to reach it. This will give you a false sense of confidence, and is likely to lead to a legacy system.

Beautiful applications will certainly attract consumers, but bugs will repel them. A nice "look and feel" won't compensate for a system that doesn't work. Therefore, a high level of trust will certainly be an asset in retaining your audience.

I imagine your next concern will be increasing your confidence level. Feel free to share your thoughts with me!