Ask any software developer a list of things they dislike doing the most and chances are testing and documentation will make the top 2.
Testing is one of those necessary evils that every software developer must wrestle with. Software developers have a unique confidence (read arrogance) that the code they write is error free and production ready as soon as their fingers leave the keyboard. We don’t need to test – it is perfect as it is!
Wouldn’t the world be a nicer place if that was the case? Sadly such hubris and confidence has killed many projects success and dented many a teams or individuals reputation.
There are many types of testing available, but the one developers are usually most familiar with is that of unit testing. This is when you take a small piece of code/method/class and subject it to many different inputs observing its behavior and output for anything out of the ordinary.
There are two major trains of thought when it comes to unit testing; test-driven development versus post-development testing. It doesn’t really matter which one that is employed, but one thing is for sure, we never can do enough of it.
Unit testing is a bit like buying fire insurance. Fire insurance is there to help pick up the pieces when the worst happens and your house catches on fire. The vast majority of people will never experience a fire in their time and as tempting as it is to stop buying the insurance, we still can’t bring ourselves from canceling the policy. Yet should fire strike, we may find that we are woefully under insured.
Unit testing is like that. You can go for long periods of time, with your unit tests never highlighting any problem. You get lulled into a false sense of security, that the code you are writing is perfect and the sprinkling of testing you are doing is merely confirming that. Of course, there is the huge possibility that your test code is not as thorough as it could be.
But every so often, our insurance policy kicks in. And when it does, we feel a joy and sense of occasion that all our efforts and work in the past have paid off. We’ve been saved.
A unit test, is coding for the future – you hope your unit test will never fail, but should it, then you have just saved yourself from a huge and potentially embarrassing problem.
Unit testing is one of the most important insurance policies a developer can purchase and while tempting as it is to let your payments slip, one day you will wish you had paid more into the insurance fund.
alan williamson 