Constant focus on quality and code health is critical for the long term viability and maintainability of software.  This focus on quality is a trademark of agile teams but you don't have to be 'doing the Agile' to focus on quality. Regardless of how you develop software, testing and in particular unit testing are an important tool to have in your toolbox.  Given the importance of unit level testing, why do so many companies struggle with unit testing and its adoption? When unit level testing is non-existent or inconsistent, the reasons fall into two main categories:

  • General misunderstanding on what a unit test provides
  • Developers aren't good / shy away from testing as it is out of their comfort zone

There is a third reason, more like a myth, that is very popular - the myth that 'we don't have time to test'.  This is false - nothing will slow you down more than writing as much code as you can without some way of constantly being able to verify you haven't broken your assumptions of the intent of the code.  We tend to hear this myth coming mostly from developers.  This comment is usually rooted in a blend of the two primary reasons with the majority of the cause coming from developers simply shying away from testing.

Lets look at the two main causes and how we can address them to build a solid focus on quality.

1. General Misunderstanding of what a Unit Test Provides

I've been involved with organizations where there is this strange belief that unit testing is complete bug prevention.  I've seen mandates from management that all project plans must include time for unit testing.  Along those lines, I've also seen 'acceptance' of bugs because a team did not write unit tests.  Lets be very clear here - You can have unit tests and still have bugs.  Its ok.  It will happen.  The important part is when it does happen, you create a test around the bug and then fix the bug; verifying that the fix didn't break any of your other tests.  This is also the simplest route to introducing tests into legacy (untested) code.

Unit tests provide:

  • Validation that the developers intent of the method, algorithm, etc is met and not broke
  • A solid framework / cushion that supports the ability to refactor and clean code
  • Means of lowering the cost of code maintenance

Unit test do not:

  • Guarantee there aren't bugs in your code
  • Prove that the intent of the developer is right
  • Ensure that the overall application will be successful

2. Developers aren't good / shy away from testing as it is out of their comfort zone

When I first started developing software, if you would have asked me if I tested my code I would have said 'Yeah, I run some mains through the app.  I don't test at a method level.  I'm a great developer, I know what I am doing.' And what I was doing was delivering buggy software.  In my defense, there weren't the great unit testing libraries then that there are today.  The point is still the same though - developers are very proud individuals.  It is hard for us to admit that this testing thing might be kind of difficult.  We know how to write code, surely we should know how to test the code we write.

Given these two main causes for unit testing not happening, what can we do to start growing a consistent approach to unit testing?

Set proper expectations. Everyone involved with delivering the software needs to understand why there is a focus on unit testing as well as what the expected benefits are.  Agree that unit testing is not nearly enough to ensure quality, but it is a solid start  Have answers for the following questions:

  • How are we going to measure whether or not unit testing is helping?
  • How can we help each other write better tests?
  • How will we know if our tests are good tests?

Review the produced benefits of unit testing. If unit testing is new to developers, be sure to meet regularly to show how it is helping and continually answer questions.

Give people time to learn, experiment, and fail safely. When a developer is uncertain about testing, give them some freedom to learn either on their current project or on their own.  A 2-day training session won't be enough, developers will only get good at testing by testing.

I am a large believer in / practicer of test-driven development.  But the reality is there are a large set of organizations and developers out there where unit testing is still not happening.  Lets start raising that bar.