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.
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!
ReplyDeleteYAY! Congratulations! I just had a similar experience but I'm not so full of myself that I had to brag about it. ;-)
ReplyDelete@Bill - I have to cling to every little victory that I can get :)
ReplyDelete