The importance of unit tests

Today I made a small change in a class in the application I'm working on. Being a diligent monkey, before adding the new feature I wrote a small dedicated test. The test failed, I added the feature, the test passed, I cleaned up a little bit (not too much, having just added three SLOCs) and finally committed the class in our SCM before hopping on to the next feature.

After a while our Continuous Integration Server pitilessly sent me a mail in which it informed me that the build was broken. No, better yet, that I broke the build, causing not one but 17 tests to fail. O shame and amazement, how was it possible? I had even written a test...

Despite all apparences, this is very good news. Why, you ask, grasshopper? Let me ask you a question: when do you want to know you have a problem? talking about software development, as soon as possible. Those 17 failures have saved me from delivering buggy code that would upset the user and set the stage for some annoying debugging sessions.

This has only been possible because of the test harness: all the time we spent writing tests has, once more, paid off well. So, without forgetting to add a test for the previously unchecked condition, I fixed the code in double-quick time.

I wish all managers understood this: writing tests is not a cost, but a tremendously effective cost saving tool.