Unit testing, for better and for worse

For the sake of this post, unit testing is defined as testing the individual functions and code routines that make up your application.  You might be doing this manually or via automated tools.  The code you are writing might be part of the command console for a NASA mission, a stored procedure, or test automation.  Now that I have gotten those points out of the way…

You have to unit test everything you write.  It’s that simple.  Nothing, not even a simple one character change should be checked in or deployed without taking time to unit test the changes.  I’ve seen one line changes result in infinite loops taking down a web server in the middle of the day; it’s not pretty. 

How do I manually unit test my code?

It’s fairly straight-forward:

• Walk through every line of code in the debugger.
• Make sure your code is being called.  Early on in my career I once spent hours trying to figure out why a piece of code was not working, only to discover it was never being called.  That was a rookie mistake, don’t make it yourself.
• Examine the variables that are being set to ensure they are set as expected.
• Use watches to track variables that are not directly in the flow of your code.  Depending on the type of application you are working on they may be changing underneath your feet.
• If you have conditional aspects of your code, manipulate variables to ensure you hit all of your code paths.
• Make sure that callers of your function are able to work with your new routine or with the way you’ve modified an existing routine.  It’s easy to inadvertently introduce side-effects down stream and you need to be looking for unplanned changes.

How do I programmatically unit test my code?

 It’s time consuming to run through your code changes and it is easy to miss things if you are making changes to code that has been around for awhile.  Just as QA teams build automated test to ensure that the important, but tedious, test cases are covered on a regular basis, it is in the best interest of the development team to automate their own unit testing.   If you are going to automate unit test, here are some recommendations to ensure you are successful:

• Have a plan.  Define the requirements for what you will automate first.
• Set goals and define a schedule.  In one company I tried to keep the goal flexible, something along the lines of write a couple of unit test a week.  We rarely, if ever, met that goal.  Assign the task and measure it like any other project.  If you do not treat it as a priority it will not get done.
• Focus on calling those functions that scare you the most.  We all have those routines that exist in the depths of our code that no one dares to touch because if we so much as look at that code it will not ever compile again.  Automate those early.
• Don’t try to automate all of your unit testing.  Make sure your developers understand that they are responsible for the quality of the code they check in and that they need to test it manually before it’s checked in.
  • Some people do advocate test driven development (TDD) or automating the test after the coding is done and prior to check-in.   This is even better.
• Tie the unit tests into your builds.  Everytime you produce a new build of your code have the unit tests run. 
• If anything breaks put the team on alert and ensure the person that broke the unit tests is on the hook for fixing them.    Enforce this.  Keep your tests and build running cleanly and you will all be happier for it.

Have I missed anything that’s important inside your organization?

 John