Over the years, unit testing has become more and more mainstream in the software development world. But this doesn’t mean that we’ve reached universal adoption.
Software groups and entire organizations still hold out for a variety of reasons. Some of those include the following:
- The developers want to, but they don’t know how.
- The developers, or at least the most influential developers, don’t actually want to.
- The group lacks time, so prioritization of getting started with unit testing simply never happens.
- Management doesn’t buy-in.
Each of these reasons could make for its own post, but today I want to focus on the last one. Specifically, I want to focus on countering this idea and building a business case for unit testing that you can present to management. Unit testing does have a cost. The team has to learn to do it, incorporate it into their process and get familiar with it, and remember that time is money. But I’ll argue here that it’s worth the investment.
Unit testing makes for good development practice. Let’s look at why it also makes for good business.
1. You Reduce Overall Defect Counts and Regression Defects Especially
First, let’s look at one of the most obvious benefits of a unit test suite. It reduces defects.
Conceptually, this makes sense to anyone, I think. When you do more testing, you’ll encounter fewer unexpected things in production. But where the unit test suite really shines is at countering regression defects, wherein something you do breaks a bit of functionality that had been working. Unit tests provide an early warning about this, preventing many such potential issues from making it to deployment.
Shorter issues/defects lists don’t just make the team feel good. They save the company money by virtue of the fact that it’s less expensive to correct issues earlier rather than later. And it also involves fewer people—fixing defects with the code still in development doesn’t have to involve support personnel or anyone who is product-focused.
2. You De-Risk Deployments
Do you know how often Facebook pushes code into production? As of six years ago, it was “really often,” so one can only imagine that now the answer is “constantly.”
How often do you push software into production?
Every few weeks? Every few months? Years? However often it is, it’s probably not as often as it could be.
Now, while Facebook has all sorts of processes and tools in place that enable this cadence, I cannot overstate the importance of automated testing in that equation. Without all sorts of automated quality checks in place, there is simply no way they could deploy as frequently as they do because it would be too risky.
So unit testing helps you with business enablement by making deployments less risky so that you can do them more often and with more confidence.
3. You’ll Spend Less Time Troubleshooting
In looking at how fewer defects save the business money, I mentioned taking up the time of fewer folks in order to address a defect. That includes support personnel, QA, and potentially folks from the product or project management side of the business. But you also save plenty of developer effort as well.
Imagine two scenarios. In one scenario, you write a bit of code, fire up the application, and see that it didn’t quite do what you intended. You make a quick adjustment and move on.
In scenario two, a production defect report winds its way into your queue. “Wow, I wrote this code like nine months ago,” you think as you start to dig into what’s going wrong.
Which one of these two scenarios do you think will involve less of your time spent on this issue?
A unit test suite pushes the preponderance of defects back to scenario one, saving the group as a whole time and thus money.
4. The Developer Feedback Loop Tightens
Speaking of saving time for members of the dev team, let’s take a look at another related benefit. This one is subtle but important.
Again, let’s consider two scenarios. In the first one, you’re testing a bit of code that you’ve just written. In order to see if it works, you compile your whole codebase, which takes a bit. Then you launch the application in debug mode, navigating menus and forms until you get to the particular scenario that you want to test. Perhaps it takes a few minutes to do that.
Now, imagine scenario two where you’ve just written that same bit of code. But in scenario two, you get a green-pass or a red-fail after only a second, without launching the application and dealing with the GUI.
This is what’s known as tightening the feedback loop. Now imagine the business impact of this tightened feedback loop across hundreds of bits of functionality and your entire team or group. That’s some serious savings.
