Why aren’t you unit testing yet?

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 at / 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 software development 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.  It’s 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 broken
  • A solid framework / cushion that supports the ability to refactor  and clean code
  • A 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 at / shy away from testing as it is out of  their  comfort zone

When I first started developing software, if you had 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 the software development process 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.


Interested in learning more about integrating the benefits of testing within an agile team? Request a free copy of the white paper: The Agile Tester

This entry was posted in Agile Development, Agile Testing, Test Driven Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>