Thursday, July 27, 2006

Test Driven Development -- Saving Grief and Pain

I recently inherited two projects at work, both in gloriously coded .NET. The first was a we'll-throw-together-a-CMS-like-web-application. Some simple concepts utilizing the webcomponents and master-template paradigms from Microsoft. Incidentally, another project was to tie into this one as a "component" to provide additional functionality. Both have zero lines of test code. Both have bugs. Both are now on my plate.

Ever since reading Test Driven Development my world is no longer the same. Having spent some time as a quality assurance engineer(2000), I very much appreciated the concepts of this book. As a developer, I feasted upon the notions of overcoming assumptions/fear based on actual test results. Starting simple, refactoring as tests passed and building a solid foundation of functional code. I finished this book months ago and immediately put into practice writing tests first. I began to think in tests and then design from there, things worked out nicely every time.

So, inheriting two development efforts (with their small portion of issues, ~60), neither of which has a lick of test code, my current outlook is a sliver of hope. A hope that, yes, we can fix things as we try to get the projects out the door. But, a serious sense of uncomfortableness pervades my being as I dig through code and fix things here and there. Deadline is approaching far too quickly, there's no time to get a testing framework in place and cram tests through everything. The best we can do is get some automated web testing in place ala Fitnesse and Selenium.

Now that the rant is done, what's the conclusion? Here it is: if you're gonna write code, write the test to go with it. That way you not only ensure the functionality of the immediate task of the code you're writing, you also spare the grief and pain of others when they look/touch/execute it.

No comments: