|
Write Unit Tests With VSTS
VSTS introduces data-driven unit testing; learn how this feature works and how you can take advantage of it in your applications.
by Jeff Levinson
January 27, 2006
Technology Toolbox: C#,Visual Studio Team System
Unit testing—the process of testing the smallest possible piece of code that can run—has been around for a long time. Unfortunately, Visual Studio itself has never provided this functionality to developers, and those who wanted to implement this feature had to rely on third-party solutions or build their own unit-testing code and procedures. To be fair, it isn't just the Visual Studio IDE that lacked integrated unit testing. None of the major development environments—and this includes Java IDEs—have integrated unit testing directly into the development IDEs. The Visual Studio Team System (VSTS) edition of Visual Studio 2005 corrects this, integrating unit testing into a cohesive and well thought-out process for creating and running tests.
Taking advantage of this functionality isn't difficult, but it does require that you think through the process carefully; otherwise, you'll create holes in the tests you conduct. I'll show you how to implement unit tests with VSTS, first by creating a small sample app to test with, then walking you through the assorted steps.
First, let's go over the theory that underpins the reasons for implementing unit testing in your applications. Unit-testing theory holds that if all of your methods run correctly, you'll find it much easier to string those methods out into a complete application. When a software system fails, it fails in a method. You don't use unit testing to perform functional testing, system testing, or integration testing. Performing those kinds of tests should be a key part of your overall testing strategy, but unit testing aims to prevent issues from ever reaching those testing stages, as much as possible. You use unit testing to detect flaws at the earliest possible moment once coding has begun. Unit testing uses a variety of tests to determine if a method performs properly.
Unit testing can rely on several different kinds of tests (see Table 1). Note that you must also take into account methods that don't return a value (such as subroutines in VB). For example, you need to be able to determine whether a given test worked, regardless of whether the test produced any values. These kinds of tests require some creativity, and you might find yourself checking values that have nothing to do with the method to get answers to these kinds of solutions. For example, you might make a separate call to your database to retrieve saved values, which can help you determine whether a given test produced the expected result.
For the purposes of the unit-testing walkthrough, use a simple class for creating a Person object (see Listing 1).
Begin Testing
You have a simple class to test with. Now create a new Class Library project called UnitTestingExample and add a class called Person. The purpose of this class is to hold information about a person applying for a position. The first and last name is straightforward, but the DateOfBirth has three business rules you must implement. First, the person cannot be born in the future (this usually indicates a miss-key); second, the person must be more than 18 years old; and third, the person must have been born after the year 1900 (again, this usually indicates an incorrect entry). A person who meets all three criteria is eligible to apply for the position.
Creating a unit test with VSTS (Developer or Tester Edition) is—in the tradition of most things Microsoft—extremely simple. Create the test by right-clicking anywhere in the Person class and selecting "Create Unit Tests… ." Selecting this option displays the Create Unit Tests dialog (Figure 1). Next, select the DateOfBirth, FirstName, and LastName methods to test, then select "Create a new Visual C# (or VB) test project." Click on OK after you select all these elements. When the IDE displays the New Project dialog, enter the new project name as "UnitTestingExampleTests." Note that you should always place different tests in separate test projects.
Back to top
|