Thursday, August 28, 2008

Unit Testing Saves the Day

I had a fantastic unit testing experience at work today. A couple of days ago I released a DLL to production that scans some text and transforms part of the text according to certain rules. An example of this would be the text that users enter into a forum post. Users would enter [b]some text[/b] and the text processor would transform that into <b>some text</b> before writing it out to a web page.

When writing the transform DLL I created several unit test that check every possibility that I could think of especially the edge cases. It was a great aid and tool to developing a robust and well tested DLL.

Inevitably as soon as it was release there an edge case came to light that I hadn't thought of and so I had to fix the "bug" in the DLL. Finding and fixing it was an absolute pleasure.

First off I took the block of text that demonstrated the bug and created a unit test that passed this block of text to the DLL and showed that the DLL was failing. At this point I haven't touched the errant transform code. I ran all the unit tests in the solution (takes about 5 seconds) and as expected they all passed the unit test except for the new one.

I then proceeded to fix the code and when done I reran all the unit tests again. This time the new test passed. This is called red/green testing. First you see the red light because it failed. You fix the code. Then you see the green light. I believe that Scott Hanselman says that it's called grey/grey testing if you're color blind.

This approach gave me an enormous amount of confidence to release the new DLL because I know that I haven't introduced any code that will break any of the previous standard and edge cases because I've tested them all again - and in only 5 seconds. Granted that it took me several hours to write all those tests but I would have probably spent at least 2 hours retesting this DLL after this fix had I not had the unit tests to do it for me.

I consider this a great victory for unit testing and test driven development and I am finally seeing my efforts in writing unit tests pay off in time saved and robust software.

3 comments:

  1. Hey Guy! Good to hear that this method of fixing bugs works in the "real world". I had this exact same experience yesterday, in fact, as we went live in production and had a few edge cases appear that we hadn't thought about. I followed the same steps: create a test that accurately reflects the problem to see the red bar in resharper, fix it, and run all the tests again. Since we have a continuous build server also running the tests, I was also caught not running my tests locally before checking in (bad developer, I know). But, that is the best way to catch problems before they get out into the wild!

    ReplyDelete
  2. YAY! Congratulations! I just had a similar experience but I'm not so full of myself that I had to brag about it. ;-)

    ReplyDelete
  3. @Bill - I have to cling to every little victory that I can get :)

    ReplyDelete