These days, Microsoft seems to offer an ever-growing number of SKUs for its software packages. Last I heard, in fact, the upcoming Windows Vista (desktop) release will include no less than six and perhaps even seven! The same phenomenon applies to Visual Studio, for which at five SKUs are presently available. Because I always wonder why developers might opt for one version over another, my curiosity about the penultimate version of Visual Studio 2005 -- namely, Visual Studio Team System -- was sated to some degree when I learned that this product version includes unit testing capabilities.
Unit test means testing the smallest executable code elements one at a time to inspect them for potential design or security policy deviations, and to check program logic and behavior to make sure it behaves as specified and is free of errors.
This has been a cornerstone of software testing methodology since the 1970s, but Visual Studio itself hasn't included this functionality as part and parcel of its capabilities until Visual Studio Team System came along. To put this apparent gaffe in context, it's also important to understand that many development environments -- including those based on Java -- also don't provide explicit unit test facilities. And even venerable value-added IDEs such as Delphi offer only limited unit test capabilities themselves in their latest and greatest versions. This has long been the exclusive province of third-party testing tool vendors.
Those interested in using an automated unit test capability are well-advised to keep this desire in mind when they design their software as well as the tests needed to warrant and inspect its capabilities. The terms "unit test" and "testing driven design" often occur near one another, for the very good reason that code designed with testing in mind is typically much easier to test (and to test both well and completely) than code designed with testing as an afterthought.
Unit test does not replace functional testing, system testing or integration testing. What it does do is prevent issues in individual classes and methods from cropping up when those other, more comprehensive testing stages are underway. Look at is this way: when software fails, it's invariably because a method fails. Unit-testing subscribes to the theory that if all methods run correctly by themselves, they'll work together more effectively and cooperate better to implement complete applications.
What Visual Studio Team System brings to this party is an ability to create tests by clicking inside a program class and selecting "Create Unit tests…" from the resulting pop-up menu. This provokes a Create Unit Tests dialog that allows authorized users (usually testers) to select object properties to interrogate and inspect during runtime. The result is a new test project that will exercise the specified elements when run.
After that, it's a matter of applying the proper test methods, which include attributes such as TestClass, ClassInitialize, ClassCleanup, TestInitialize, and TestCleanup, all of which give you a good idea of what you're up to. A testContextInstance object exists to provide access to any and all information about tests underway, and provides a windowing service to perform code tracing, data-driven testing, and more. Likewise, there are explicit methods to check exceptions. Some rely on checking for expected exceptions, while others require traps to catch unexpected values and behaviors.
All this adds up to testing facilities that even work with data sets from a local database to help create data-driven test sequences. This functionality is indeed valuable, but individuals and organizations must decide if it's valuable enough to warrant the $5,000-plus MSRP that Microsoft put on its price tag, or the $3,500-plus "street price" you'll have to pay for this version of Visual Studio 2005. Those for whom such numbers give pause must weigh the costs and consequences of using other tools instead or handling unit test manually. Those who can afford this functionality can't help but find it extremely useful.
Ed Tittel is a writer and trainer whose interests include XML and development topics, along with IT Certification and information security. E-mail firstname.lastname@example.org with comments, questions, or suggested topics or tools to review. Cool tools rule!