Unit Testing — Back to Basics
I’m drinking a lot of cool aid at Lab49 (tastes great, less kludgy). Its a place where phrases like tail recursion, statistical programming languages, and Dependency Injection/IoC, are regular topics of conversation. In other words, geek heaven. So, of course I’m going to use all the tools and tricks I’ve got (otherwise known as best practices) and Unit Testing is fundamental.
Why should you unit test? Even Microsoft knows the answer, but here’s a more complete answer — I doubt I need their product though. Short answer is it greatly helps you deliver and maintain, upgrade and reliably (regression) test software.
The benefits are huge, but the costs are actually minimal. When a unit test is created in tandem (or before, you TDD purists) with creating code it can be used to test each small piece of the program more quickly and more often without running and clicking through the UI. I feel that writing unit tests is actually less work than doing the testing interactively as I write code. And writing code that that can be easily unit tested means the code will be more modular and less coupled. A lower spaghetti factor ;).
It’s been a while since I was using unit testing regularly. I strayed too far into the realm of custom per project testing frameworks and now I’m happy to start over with with the basic testing frameworks. Back in 2005, the last time I recall heavily unit testing, there was really only NUnit and TestDriven.net (yes, I’m still just a .Net guy. Move along Java folks, nothing to see here). Now there’s MBUnit, XUnit, PUnit, and probably XYZ Unit. Not to mention Microsoft Unit Testing built into higher versions of Visual Studio. And check out PEX for automated creation of tests. It looks cool but unfortunately is only in version .18, that’s a bit shy of the magic number for me to give it a test drive.
Of course, I started with MS Unit Testing, since its built into Visual Studio. Its there, why not use it. Well, its (very) slow to start up, its only there on the higher more incredibly expensive versions of Visual Studio, and its design of running code out of test results subdirectories makes accessing local file resources difficult. The file resource issue was the last straw. After reviewing the available testing frameworks I chose good old reliable NUnit. Fifteen minutes later, the tests that I couldn’t make work with MS Test were passing in NUnit — a happy ending.
As a post script, a friend mentioned how ridiculous it is that MS would invest in creating their own testing framework when so many really good open source ones are available. Many companies contribute to the open source projects rather than building a new less functional wheel. I couldn’t agree more. I’m not of the opinion that Microsoft is Evil, well, no more evil than Exxon, but they’ve got it wrong this time. I don’t see how their crappy unit testing makes the high end Visual Studio any better or encourages anyone to part with an extra buck for it. Though it might help their FUD campaign, which is evil.