High-Quality Unit Tests

by Alan S. Koch, PMP

Most software developers are not good at unit testing. This is not surprising for many reasons. First, they have generally never been trained in how to do it. Then there is the fact that they would rather be writing new code than testing what they already wrote. And of course, we must consider that most programmers are not judged on the testing they do.

However, if we look at all of the reasons for programmers' reluctance to focus on unit testing, it becomes evident that these reasons feed on each other. Who likes to do something he has never learned to do well? And who wants to invest the effort to learn to do something she is not judged on? When our programmers' jobs are to "write code", why would we expect that they would work at being good testers?

But our programmers' jobs are not to merely write code: they are to write good-quality code that can be used by real people to do real work. Many tools and techniques are necessary to achieve that end, and unit testing is one of them.

I just held a workshop with a group of software developers to discuss Unit Testing in their company (as part of an assessment of their testing processes). While I was not surprised to find that unit testing is done in a rather random way, I was surprised at the degree to which the developers want to get better at it! Far from resisting changes to how they Unit Test, this group is frustrated by their current practices, and want to improve them!


For example, Scott started the discussion off by complaining, "I'm not sure when I am done with Unit testing." Without clear guidelines about what should and should not be done, he finds himself randomly trying things out, but never feeling like he has done enough. After a while, management cuts the testing off, but even then, Scott worries that what he did was not enough. And sure enough, problems found during system testing or in the field are often things he "should" have caught himself.

Scott knows he can do a better job of Unit Testing, but doesn't know what that "better job" would look like. And he is given no guidance other than "Unit Testing must be complete..." As we were wrapping our discussion up, I asked what those folks would like to see in my recommendations. Scott was the first person to speak. "We need structure. We need to know what are the expectations for unit testing; and it needs to be quantitative so I can report my actual status!"

Wow! I couldn't have said it better myself!

I often work with or train QA folks and testers. Too often they complain that the developers don't care about quality: that they are satisfied with whipping up poor code and letting someone else find all of the problems in it. But when I talk with the developers themselves, as I did today, I find a completely different story. They do care about the quality of their work. But between the time pressures from management and their lack of testing expertise, they have a difficult time doing anything constructive about it.

How can we support our developers in doing a better job of Unit Testing? As with anything on our projects, there are three parts to that answer: People, Processes, and Tools.

  • People (the developers themselves) need to have appropriate skills, knowledge and motivation for the job.
  • Processes must be designed to help those people apply their skills and knowledge consistently and effectively.
  • Tools must be provided to support people's ability to execute the processes efficiently.

Upgrading our developers' ability to Unit Test can be done in many ways. Training is an obvious first step. An abbreviated form of the training that many testers receive will go a long way toward providing them with the knowledge they need to build good testing skills. This training should include how to identify useful test cases, where to look for likely problems, and how to identify negative test cases.

If you have testers in your organization, then you can supplement this training by establishing mentoring relationships between developers and testers. Replacing what is often an antagonistic relationship with one of respect and learning will yield many benefits beyond better Unit tests! Even without professional testers, you can still identify those developers who pick up testing skills quickly to help their peers along.

And to meet their motivational needs, you may need to re-think your system for recognizing and rewarding developers. Think beyond mere code production. Clean code; high-quality code; code that works right the first time is what we really want! We must reward the results we want.


People with the necessary skills, knowledge and motivation need good processes to support them. By "good" I do not mean "burdensome"! In fact, good processes are just the opposite. A good process is one that helps people to be consistent in how they do their work without getting in their way. Good processes are almost invisible, sometimes causing people to think they don't need a process, when in fact they already use one.

Our development process needs more than just a placeholder called "Unit Test". It needs to lay out explicit guidance about what should be done, and (to the extent it matters) in what order. The developers may need checklists, or possibly procedures. Maybe they need guidelines or standards for what should be included in their tests. Whatever they need to consistently do good Unit testing, provide it for them. But don't go beyond what they need. Too much process is a burden, and not helpful.


Finally, we will probably need to get some tools to help with Unit testing. Many tools are available, for example:

  • Automated tools that will allow them to create test cases once and run them over and over again
  • Complexity analyzers that can guide them to re-factor code that is overly complex or convoluted
  • Coverage analyzers that can show them which lines of code have been tested, and which are still big question marks
  • Profilers that can help them to see how resources are being used and identify performance bottlenecks or memory leaks
Good Unit Testing

Yes, our developers can do good Unit Testing—if we provide what they need: the opportunity to learn about testing and master those skills, a reward system that values good testing, processes that make good testing easy to do consistently, and tools that support them in doing good testing. These are all things that are within our control.

The benefits we will realize on our projects will more than pay for the time and cost of doing these things. And it will make work much more enjoyable for our developers (who will be able to produce the quality they strive for), for our independent testers (who will no longer have garbage thrown "over the wall" to them), and for the end users (who will receive a system that works well). That is win-win-win!

Related Items on ProjectConnections
Ever wondered what a unit test plan actually looks like? We have an example for you to review. Rodney Parkin of IV&V Australia has provided his take on Software Unit Testing for you to consider as well. We have many more testing documents and plans available as well.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy