Business value of unit testing on a project
Over the years, we’ve helped a lot of organizations install and improve their unit testing practice. As you can imagine, I’ve also heard a lot of concerns over and objections to unit testing. At the top of that list? Extra time it will take.
In this article, we would like to share our vision of what business value unit tests carry and why they should be implemented when developing software.
We always write tests, even if it is not required by a customer. Our standard unit tests coverage is at least 80%. In the long run of the project, this is cheaper than not writing them. It is essential for all more or less serious products to be covered by tests. If your product is multifunctional, it should be covered by tests.
Focus on Business Value
This may seem like a long introduction to this chapter, but it really cuts to the core of the business value for unit tests. During development, why do developers compile, run, and debug? Well, they do it to see if their code is doing what they think it should do. Write some code, then make sure it’s doing what you expect. So why write unit tests? To make sure your code is doing what you expect, and to make sure it keeps doing what you expect via automation. The core business value of unit tests is that they serve as progress markers, sign-posts, and guard rails on the road to an application that does what you expect.
Unit tested applications are more predictable and better documented than their non-unit tested counter parts (assuming the same amount of API documentation and commenting is done), and there is an enormous amount of business value in predictability and clarity of intent. With a good unit test suite, you’ll know in minutes if you’ve introduced a regression bug.
Without that unit test suite, when will you know? When you run the application GUI? When QA runs it a week later? When the customer runs it a month later? When something randomly goes haywire a year later? Each one of these delays becomes exponentially more expensive.
That’s not the only value-add from a business perspective (and I’ll list some other ones further), but it’s the main one, as far as I’m concerned. It also explains why the notion that you need to carve out some extra time for unit tests and figure out whether the customer wants them or not is preposterous. Do you think the customer is going to get angry if you explain that part of your development process is to execute the code you just wrote to make sure it doesn’t crash? If the answer to that is “no, of course not, that’s ridiculous”, then you also have the answer to whether or not a customer would care if you happened to automate that process.
Of course, one thing to bear in mind is that a customer may not want to pay for you to learn on the job to unit test, and that’s a fair point. But if the customer (or your company, internally, if you aren’t a consultant) doesn’t want to foot the bill for this, then you should strongly consider picking it up on your own and then switching customer/company if they don’t buy in to something as fundamental as automating predictability.
Unit tests are the software equivalent of accountants practicing double entry bookkeeping, doctors washing their hands, electricians turning power back on before leaving and plumbers doing the same with the water. Imagine if your plumber sweat welded a joint for your new shower, sized it up and then said, “meh, I’m sure it’s fine” and left without ever running the water. That’s what tens of thousands of us do every day when we just assume some piece of code works because it worked a month ago and you don’t remember touching it since then. Ship it? Meh, sure, whatever — it’s probably fine.
The business value of unit tests is a stronger assurance that we know what’s going on than “meh, sure, whatever.”
Test Suite and Reduction of Deployment Risks
If you have developers writing good unit tests, you’ll develop a nice, robust unit test suite over the course of time. Developers will run this test suite constantly, and they’ll even have the team build to run it in a production-like environment.
With each test they write, they secure just a little bit more of the application’s behavior against regressions. Regressions typically happen when developers change something and accidentally break functionality that worked previously. If you’ve lived in the software world, you probably know how maddening this is, especially when a bug makes it to production and users find it. Oops.
Your unit test suite guards assiduously against these regression defects. And, it provides concrete evidence that new functionality behaves as expected. All of this adds up to the very real business outcome of deploying with more confidence. You’re far less likely to need to dedicate time to support calls, triage, and patching. And you’ll look better to your users.
Tighter Feedback Loop to Save Time
The benefits, however, extend beyond what happens following a deployment. A nice test suite also helps you realize labor-savings benefits.
In the agile coaching world, you’ll find a pretty iconic graph of the cost to fix a defect as a function of time. If you catch a defect as you write the code, you can fix it immediately, as you would with a typo. But if you don’t catch it, and you commit it to source control, things get more expensive. Then someone in QA might catch it during their hours of testing. They log it in the bug tracker and kick it back to the development team, who spends a good bit of time reproducing the issue, tracking it down in the code and fixing it. And, if months or years elapse and the defect is discovered in production? Well, by then, you’ve probably built on top of it, making the cost of change catastrophic.
A unit test suite makes you much more likely to catch errors sooner than later. It does this by tightening the feedback loop. So with a good test suite in place, you’re far less likely to spend disproportionate amounts of time tracking down, reproducing, and fixing issues and the code you’ve built on top of them.
More Business-Friendly Software Architecture
Speaking of the cost of change, unit testing helps with this in another way as well. Michael Feathers once gave an excellent talk, called “The Deep Synergy between Testability and Good Design,” and I completely agree with his arguments. Testable code is better code, as measured by how easy it is to change that code.
Testable code tends to have “seams” that serve as nice points of modularity in your application. It’s hard to test code that writes to databases and files, so committed unit testers will “mock” files and databases to facilitate their testing. As a byproduct, it becomes easier to swap a database or file out in that application than in one that doesn’t bother to create a seam between application code and the database.
And, it probably won’t surprise you to learn that people who write a lot of unit tests get good at writing testable code. That happens by simple practice optimizing their own effort. The upshot is that shops focusing on tests tend to have architectures that make future changes easy. This, in turn, helps the business by keeping the cost of change and the software’s total cost of ownership lower.
Credibility
I’ll close by offering one last, more philosophical benefit. It feels weird to say, but it does reflect reality. Being part of or managing a group that performs unit testing has positive implications for your career.
Like it or not, the software world has spoken and automated testing is considered the right answer. As such, people with experience developing in this style or managing it will be more marketable. That’s a personal benefit for individuals, but it also adds credibility to the group as well. Clients, customers, executives, and really any stakeholders in a software group will find themselves more inclined to give them the benefit of the doubt if they make good faith effort at adopting what the industry deems best practices.
Make no mistake. Unit testing has plenty of tangible benefits, including the ones I’ve outlined here. It will make the team better, save the business money, and have good implications for the careers of all involved. As they say, a rising tide lifts all boats.
