Unit Testing: Can You Afford Not To?

Unit testing is fairly common these days as more and more people understand the benefits; however, you may still run into a client or manager who is not convinced. These people tend to think unit testing increases development time and cost, or they feel that unit tests are redundant since a QA department is also testing the application. If you’ve ever heard “we don’t have time for unit tests”, “you’re a developer, leave testing to QA”, or “I’m not paying you to write tests” then you know what I’m talking about.

These encounters can be quite frustrating for a developer or project manager who wants to leverage unit testing. While there might be a temptation to just unit test anyway without the blessing of a client or manager, it is more useful to help these people understand why they are mistaken about unit tests. I have found that this misunderstanding is often because they don’t realize that testing is actually a cost saver instead of just an additional cost.

But how to vocalize this point in a way they will understand?

The bottom line is that unit tests save time and therefore money. This is a common stumbling point for people to understand (especially non-technical people) since it is counterintuitive. To them, testing is just “more code” so it has to increase development time and cost. To combat this erroneous perception, it is important to point out how unit tests save time for both developers and QA.

Unit testing reduces the time it takes for the developer to verify their code. Instead of needing to find out if this bit of code which is in the middle of a long workflow works, I can write and run a targeted unit test in less time than it takes to fire up the app, login in, start the workflow, goto the exact spot in the workflow, etc. Since the test is repeatable and automated, writing the test is a one time cost which I can then easily re-run to verify my code at any point in time and for as many times as needed. This becomes an even bigger time saver when code needs to be changed. Everyone makes mistakes, and it is easy to accidentally break something when making a change to several month old code which you didn’t write. Unit tests help ensure that a developer catches any mistakes right when they happen, and allows them to be fixed quickly.

It is at this point that QA is often brought up: “a developer doesn’t need to verify code because QA takes care of that”. At these times, it is important to point out how the QA process is more costly, especially if the issue could have been prevented with a unit test.

If someone in QA notices a problem, they need to stop verifying other parts of the application to deal with the problem. You have just reduced their productivity. Now, the QA person needs to write up a ticket which includes detailed instructions of how to recreate the problem. You have just increased the amount of work needed to be done by QA. Now, the developer gets the ticket and needs to take a look at the issue instead of working on new features. You have just caused the developer to context switch, which reduces their productivity. If the issue is for code the developer wrote a while ago (or didn’t write at all), they need to spend time getting familiar with the code. Again, more context switching and more time spent not adding new features. Even after fixing the issue, the QA person will still need to verify the fix by retesting that same part of the application. The QA person is made even less productive because they are testing that part of the system again instead of parts which haven’t been tested yet.

Now, imagine how much more time is spent if the developer is having problems reproducing the issue or if the QA person notices the problem isn’t really fixed and needs to reopen the issue. You will need to repeat most of that process, further compounding time spent. What happens down the line when code is changed and this specific issue occurs again? Yup, you have to do this whole dance again.

Unit tests won’t prevent this from happening all the time, nor will it handle the kind of complex scenarios and verifications which QA does which are difficult to do in a unit test. However, it will significantly cut down on the number of easily preventable issues which detract QA from doing more important testing (and the developer from focusing on new features). When the developer writes a unit test to prove the issue is fixed, he will be preventing it from happening again in the future (which means time is saved because the issue won’t be reopened or crop back up some point in the future).

Basically, unit tests are a way to automate certain parts of the development and QA process which don’t need to be done by a human every time. This allows a more streamlined process which makes developers and QA people more efficient and productive, and frees them up to focus on things which generate revenue instead of hunting and fixing bugs which didn’t need to be there in the first place.

There are plenty more reasons why unit tests save time (the design benefits coming from TDD is certainly not to be forgotten); however, I have found this example to be the most effective because it is the easiest for non-technical people to visualize the cause and effect relationship unit tests have on the bottom line.

I have also encountered this problem, and will be using your post to help explain it to others.

I have noticed that if you can phrase the discussion in terms of time, like you have done, or money, it starts to resonate with managers more.

If you currently have a staff of 3 QA people doing all the testing for your app, and a good portion of what they are testing could have been caught with better unit tests and other automated testing strategies, the ‘cost’ of writing unit tests should be more than offset by the ‘savings’ from a more efficient QA team.

If you can get catch those problems as close to the development process as possible, where its cheaper to fix them, you can reduce the QA resources you need for that project. If writing better unit tests mean you can go from 3 QA people to 1, how much is that worth? Its not just the rate of that person, its also all the other indirect savings of keeping your team smaller and more nimble. Imagine 2 less people going to all those meetings, reviewing requirements, emails, standups, bug priority meetings, etc.

How much more productive could you be, and how much better could your product could be, if you could take those very valuable and knowledgeable QA resources, and put them on to more important problems?