In-Depth

Write Tests Before You Code

Use the Test-Driven Development methodology in Visual Studio Team System to write tests and improve the quality of your code.

• By Jeff Levinson
• 04/01/2007

Welcome to Visual Studio Magazine's new online column on Microsoft Visual Studio 2005 Team System (VSTS). Twice a month I will introduce you to concepts in VSTS, for beginners and professionals alike. If you have a question about an aspect of VSTS that you would like to suggest I address in a future column, please send it to [email protected].

In this debut column, I will demonstrate how to use Team Edition for Software Testers for writing code in accordance with the Test-Driven Development (TDD) methodology. Oddly enough, many developers still do not write unit tests for their code, much less write tests before they write code! Using the TDD process, you write tests before you write code. Two of the most compelling reasons for this approach are (1) all code you write will be testable, and (2) you will not write any unnecessary code. At the very least, even if you decide not to adopt TDD, you will see the value of the unit-testing features in Team System and incorporate them in your process to build better applications.

There are advantages and disadvantages to using TDD. For agile methodologies, incorporating TDD offers a huge benefit because you do not conduct significant upfront design in agile development. TDD does not allow you to create class diagrams and perform optimization up front. However, TDD does make it extremely easy to refactor code you've written. TDD generally prevents you from "gold plating" an application — that is, adding code that is unnecessary and often unused — and it is incredibly simple to add to an application without breaking the whole thing!

Team System implements a generic unit-testing framework that can be adapted to virtually any situation. Team System can be used for TDD, but not in the purest sense of the word. In the TDD process you create a unit test that will break ("red"), fix the method being tested so the test passes ("green"), and refactor — then start the cycle over again. Because you create the test before the method, the test is guaranteed to fail. Typically when performing refactoring, you have a somewhat larger body of code to work from. The good news is that for the purposes of regression testing, almost all of your tests are written already!

Using VSTS you can generate method stubs from your unit test, but you need to create the class that is going to house the method stub first. This is really the only limitation when using VSTS's unit testing from a purist's perspective.

To create your first test, create a new VS Console application. Add a new public class called "Calculate." Select Test > New Test from the main menu, and select Unit Test from the Add New Test dialog. Name the test "CalcTests" (this is not actually the name of the test but is used as the name of the class).

One best practice I suggest is to append "Test" to the name of the method you are going to test — if you write more than one test per method, which is likely, either describe the test or append numbers and enter a description. For example, you may have "AddTestPositiveNumbers" or "AddTest1" with a description. (To enter the description select Test > Windows > Test Manager or Test View and select the test, then add a description in the Properties window.)

Create a new test project (your tests should in generally always be separate from your application code base) and call it "AppTests." Change the name of the test method to "AddTest." Next, add a reference to the ConsoleApplication1 project to the AppTests project and import it in the CalcTests module.

Next, add the following to the test method (entire method is shown for reference):

        [TestMethod]
        public void AddTest()
        {
            int x = 5;
            int y = 10;
            int result = 0;
            int expected = 15;

            Calculate c = new Calculate();

            result = c.Add(x, y);

            Assert.AreEqual(expected, result,
 "Values are not equal");
        }

When you enter result = c.Add(x, y); "Add" will be underlined and you'll be given the option to generate a method stub. When you select this option, the following stub is generated in the Calculate class:

        public int Add(int x, int y)
        {
            throw new Exception("The method or operation is "
            + "not implemented.");
        }

The Assert method is a class with a collection of static methods that allows you to evaluate one or more values that you use to determine if a test passes. Run the test by selecting Test > Window > Test Manager or Test Viewer, check the AddTest entry, and select the Run Checked Tests button. The test will, of course, fail. Change the Add method to read:

        public int Add(int x, int y)
        {
            return x + y;
        }

Compile the application and re-run the test — this time it passes. You're on your way to developing code with TDD.

VSTS allows you to perform many more advanced operations, such as extending the testing framework, creating data-driven tests (test data supplied from a database), checking code coverage and providing other tools to help improve the quality of your code. I will explore these features and more in future columns.

• Get Code Download