I spend a lot of time at Codecov talking to people about code coverage. It’s at the core of what we do, and most software engineers are quick to pick up how useful it can be and why they need it in their systems.
However, most of my friends and family have no idea what I do.
Because of that, I’ve gotten pretty good at describing code coverage to all sorts of people in my life. If you expect to get cornered at a holiday party this year like I do, here are some techniques to explain code coverage and its benefits to your captive audiences.
To your non-technical friends:
I write a lot of code, most of which breaks at some point. To cut down on this, I give my code tests to pass before it goes live. Sometimes, however, I miss things. I forget to build a test for some piece of code, and then, predictably, it breaks. Code coverage tells me what parts of my code don’t have tests. That way, I know what tests I need to write to make my code break less.
To your boss:
Some of our systems, particularly those closest to customer data, need to work flawlessly. Engineers are scared to make changes to them, because a lot of this code is old and the original authors aren’t at the company anymore. If we don’t put in processes to help us deploy more confidently, we are going to miss some bugs and side effects. Covering that code with tests will help us prevent future changes from causing regressions. We can use code coverage to find this untested code.
To your reports:
When we want to move quickly with features, we end up overlooking easy bugs that we shouldn’t have. This ends up taking more development time than it should, and our customers get angry using our buggy features. If we want to move from being a reactive team towards being a more proactive team, we need to use tools that help us uncover edge cases before they reach customers.. Code coverage tells us what code is not executed during testing and will help save time in the long-run, letting us deploy with more confidence.
To your 5-year old nephew:
Before Fortnite adds a new level, they have to test it out to make sure it doesn’t break. It’s someone’s whole job to make sure that every level gets tested. Sometimes they need help testing these levels, maybe with a new shield or finding the best places to hide. They use tools to help them know that they’ve gone through all those features. I work on that kind of tool, too.
To your executive team:
We don’t want to waste our engineers’ time, and adding process for the sake of process isn’t helpful. But we are bearing a lot of technical debt from previous sprints that haven’t been addressed. We can prioritize features based on their business value, but we have a much more difficult time doing that with bug fixes and refactors. These changes take a significant amount of planning and usually require a senior engineer to handle. Code coverage will help us determine where we should spend time to write tests so we spend less time shoring up issues in the future.
To your parents:
Mom, Dad, I have a job that pays me real money. Please stop asking me if I’ve gotten laid off.
Code coverage is no longer a nice-to-have feature that looks retroactively at your codebase. And it’s not only just a metric that engineers and managers point to for code quality. In the era of Git and CI/CDs, code coverage is predictive and allows teams to move quickly and with confidence.
