Test Driven Development with Visual Studio 2008 Task Lists

Totally Integrated TDD Example

In my previous blog post, Integrated TDD Environment, I explained how you can do all of your Test Driven Delopment steps without leaving the Visual Studio 2008 IDE by adding a new Task List comment type: TEST

In this blog I will demonstrate step-by-step using a simple example how create a functional class from scratch using integrated TDD within VS 2008.

The Requirements

Every software development project should begin with requirements. Our example will have the following requirement:

• Provide a web form where the user can enter a temperature in either Fahrenheit or Celsius and see the conversion to the other system.

Our design will separate the user interface from the business logic. For our example we will only test the business logic. We start by creating a new Windows class library project. Name it WebControls. Delete Class1.cs and add a new class named Temperature. This is the class we will build using TDD.

Generate the Test Project

Since we are doing TDD, then all of the development will be driven from our unit tests. We want to have a test project for each project in our solution and a test fixture for each class in each project. Lets add a new project to our solution by selecting Project Type, "Test" and the "Test Project" template. Name the project "WebControlsTestProject."

Select WebControlsProjects in the solution explorer and select "Add" then "Unit Test." You can then browse all the projects in your solution. Select the Web Controls project and the Temperture class:

Visual Studio will create your unit test module shell with the necessary includes and several procedures, including many that are commented out in the "Additional test attributes" region, including setup and tear-down routines, which you can easily uncomment and use.

Since we created a class named "Temperature" then the Visual Studio unit test wizard created a class called "TemperatureTest." We will add our test list in this module.

Add TEST to the Task List Comment Tokens

Start by defining a new Task List token for the test list. On the Tools menu select Options, then select Task List from the list on the left of the options dialog.

Type "TEST" in the Name field, click Add and then OK. Now you will be able add test list items anywhere in your code by adding a comment that begins with the TEST: followed by the description of your test:

// TEST: Here is a unit test description.

This comment now appears on the Comments Task List:

Create the Test List

We are ready to create our test list. We start with our requirement and test for the following:

• Valid results
• Error conditions
• Limit conditions

If you remember back to 6th grade, these are the key facts concerning conversion between Fahrenheit and Celsius:

• Water freezes at 32 F and 0 C
• Water boils at 100 C and 212 F
• The formula for converting is C = (5/9)*(F - 32)
• There is a temperature called "absolute zero" which is the lowest posible temperature. It is -273.15 C or -459.67 F

We can make of these facts to generate the initial test list and then add more tests as we think of them. Open the TemperatureTest.cs class file, move to the end, and insert the following comments before the two end brackets for class and namespace:

// TEST: Verify 32 F converts to 0 C // TEST: Verify 0 C converts to 32 F // TEST: Verify 100 C converts to 212 F // TEST: Verify 212 F converts to 100 C // TEST: Verify that the Celsius temperature equals Farenheit minus 32 times 5/9 // TEST: Verify that the Farenheit temperature equals Celsius times 9/5 plus 32 // TEST: Verify that a negative Farenheit temperture converts to the correct value // TEST: Verify that a negative Celsius temperture converts to the correct value // TEST: Verify that entering a temperture less than -273.15 C throws and exception

} }

If this doesn't cover all the code we need to write, it should give us a good start. We can easily add new tests as we think of them just by entering comments. Our VS Task List should now look like this:

Implementing the Tests

We're now ready to start TDD. Let's start with the first test, "Verify 32 F converts to 0 C." You can double-click the item in the task list to jump right to it. Add the following code below the comment:

Now we want to write some code and see if the test passes. First we have a design decision to make: do we want this class to require an object to be instanited or use static methods? Static methods are easier to call, but if we need data persisted within the object we have a problem because static methods are global. If you look back at the requirement we see that we need to support a web form, which would have a view state, so our temperture convertor probably won't need to remember anything. We'll start with a static method and hopefully that'll get through all the tests.

We start by writing the code in the test first, then updating the Temperture class so that it compiles, and eventually passes the test.

It seems reasonable that the Temperature class would have a static method named "ToCelsius" that takes a double (since we can have fractions of a degree) representing the Fahrenheit temperature and returns the Celsius temperture as a double.

We have not written the "ToCelsius" method yet, so Visual Studio puts a wavy red line under the method indicating a syntax error. Here is where the refactoring capabilies come in handy. Hold the mouse over the "ToCelsius" method name then you get a drop list where you can select "Generate method stub for Temperature.ToCelsius." We do so and now we can compile and run the test. Of course it fails:

To fix the test we right-click the ToCelsius method "Go To Definition," and then fix the method with the minimum amount of code for the test to pass:

Run the test again and now it passes:

Our first test is done, so we remove it from the list. Since our Task List is driven by comments then we need to delete the TEST: from the comment. We can leave the description so that we have some documentation left behind.

The Task List now has 8 tests remaining. The next test is to verify that 32 F converts to 0 C. If we follow the same method as before we write this test:

We implement this method to get the tests to pass:

And we run all the tests and verify they pass:

Note that there are actually 3 tests, because Visual Studio automatically adds a test for the class constructor. Since we're using static methods and don't do anything in the construtor, then I changed the default test to simply verify that the class can be created:

When we did the freezing point tests we wrote the minimum amount of code by simply returning the hard-coded expected results of 0 or 32. We could do the same with the boiling points, but let's skip ahead a couple tests and see if these two tests don't take care of some of the others:

// TEST: Verify that the Celsius temperature equals Farenheit minus 32 times 5/9 // TEST: Verify that the Farenheit temperature equals Celsius times 9/5 plus 32

Again we start by writing the test code first, then adjusting the class methods for the tests to pass. We can use the same to static method to convert Fahrenheit to Celsius and copy the previous test, then edit the code to create the test below:

For the above test I picked a random temperature, 72 F, and then calculated what the result should be. We now run the test, and since our "ToCelsius" mthod is still hard-coded to return 0 then, of course, it fails:

We can now go to the ToCelsius method and fix it:

Let's rerun the tests and see what happens:

Notice that not only does the ConvertToCelsiusTest pass, but the previous tests also pass so that we know we have not broken any of the previously working code with our new changes. That's one of the benefits of TDD: as you build your software in small steps you build a collection of regression test that get re-run at each step, immediately alerting you when when new code causes previous code to fail.

At this point I won't bore you too much more with doing the next few tests step-by-step. The Convert to Fahrenheit test can be done the same way we just did the Celsius conversion, and the two boiling point tests can be added and run to check that our formulas work at both ends of the scale:

Now we have one more test to do:

// TEST: Verify that entering a temperture less than -273.15 C throws and exception

But this suggests one companion test, verifying that absolute zero on the Fahrenheit scale also generates an exception. We can quickly add tests as we think of them by simply typing in a comment:

// TEST: Verify that entering a temperture less than -459.67 F throws and exception

Let's do absolute zero on the Celsius scale first. This is different from the previous tests, because instead of testing an assertion, we want to test that certain will generate an exception. So we need to use the ExpectedException attribute. We add it as a decoration inside square brackets between the TestMethod() attribute and the unit test method declaration. It takes a parameter for the expected exception type, so that's the first thing we need to decide, the type of exception we should generate. We could define our own custom exception, but lets just use an Overflow Exception, since we are overflowing the range of valid temperatures. Here's what the test code would look like:

Notice that we added the ExpectedException attribute and gave it the System.OverflowException parameter, using the typeof() function to provide the correct type for the parameter. The test code itself does not need to use the Assert method. The test method just needs to execute code we expect to generate the exception. So we take the out-of-range Celsius value, give it to the ToFahrenheit method, and try to assign it to a variable. When we run this test we get the following result:

The code did not throw an exception, therefore the test failed. We now adjust the ToFahrenheit to throw the expected exception:

The test now passes:

The process for the absolute zero Fahrenheit is similar. We add the test, adjust the code ustil it passes, then we can re-run all our tests and they now all pass:

We keep removing the TEST: attribute from our comments each time a test passes and our Task List is now empty:

Summary

This demonstrates how you can do TDD, Test Driven Development, without leaving the Visual Studio 2008 environment. We added a new task type, TEST and then managed our TDD test list through the Task List. We used the integrated unit test and refactoring capabilities of VS 2008 to build a new class from scratch using the red/green/refactor methodology.

Using Web User Controls to Create Rich Internet Application Subassembies

Web user controls provide an opportunity to combine multiple related controls into one neat package. If you combine standard form elements with components from the AJAX control toolkit then you can build a library of rich internet application elements.

Example: A Numeric Entry Control

To illustrate what I mean, let’s consider a basic web user control for numeric data entry. Of the basic HTML form elements, text box, check box, list box, radio button, etc., the only one that would work for entering numbers is the text box. But the text box will allow you to enter either text or numbers, so if you have a data entry field for a numeric values then you would need to supplement it by adding either server-side or client-side code to prevent the user from entering anything other than numbers.

Since this is a common programming task, it would be nice if we could make a generic control for numeric entry that we could then easily reuse anytime we need numeric data input.

The requirements for this control are:

• It will only accept numeric values
• You can set a minimum and maximum value
• You can set it accept either integers or decimal numbers
• You can set it add comma separators if desired

AJAX Control Subassemblies

We can make use of Microsoft’s AJAX Control Toolkit to perform the client-side tasks which will limit the user to entering only numbers within a specified range into a textbox.

The AJAX Control Toolkit uses the “extender” design pattern. What this means is that instead of creating specialized controls that that will do one particular task, they offer control extenders which all have a “target control” parameter. The extender adds some additional capability or feature to its target. Different extenders can operate on the same target control. This gives more flexibility for adding exactly the features and behaviors that you desire in a particular control.

Scott Guthrie has a great discussion of ASP.Net control extenders in his blog.

The disadvantage is that every time you want to add a particular type of control that makes use of multiple AJAX extenders then you have to combine all the parts together and wire them up for each and every field on every web page. We can give up a little flexibility but still have very useful generic components by creating web user control subassemblies that combine elements that are commonly used together.

The properties of the subassemblies are:

• Two or more extenders are pre-wired to a common target control
• The web user control assembly exposes public properties that control the key attributes of the extenders
• The extenders will have reasonable default values so that you can drop the web user control onto your web page and use it with a minimal amount of effort, setting only those properties that are unique to the specific field.

AJAX Extenders for our Sample Numeric Control

We can meet the above requirements be making use of the following AJAX extender controls:

Control	Description (from http://www.asp.net/ )
MaskedEdit	MaskedEdit is an ASP.NET AJAX extender that attaches to a TextBox control to restrict the kind of text that can be entered. MaskedEdit applies a "mask" to the input that permits only certain types of characters/text to be entered. The supported data formats are: Number, Date, Time, and DateTime.
RangeValidator	The RangeValidator server control tests whether an input value falls within a given range. RangeValidator uses three key properties to perform its validation. ControlToValidate contains the value to validate. MinimumValue and MaximumValue define the minimum and maximum values of the valid range.

The range validator is actually a standard ASP.Net control but it does use the same extender design pattern. You will often combine validation controls with text boxes and AJAX extenders. By preassembling these parts you can save yourself some work.

In my next post I will take you step-by-step through a real-world example by creating a web user control subassembly for numeric data input.

Summary

The AJAX Control Toolkit and other ASP.Net components such as validators use the Extender Design Pattern, which makes them very flexible for adding features and behaviors to existing controls and allowing you to pick and choose multiple extenders to work on the same control. The drawback is that you have to do a lot more work to custom define the features and behaviors of every individual control that you desire to have a rich user interface. You can reduce this effort by creating a subassembly that combines ASP.Net AJAX and other web interface components into a web user control.

One example of such a web user control is a numeric data input control which I describe here and will create in my next post.

Use Visual Studio Task List to Create Test Lists for Test Driven Development

Integrated TDD Environment

Introduction

The Visual Studio 2008 SP1 now includes integrated unit testing, making TDD (Test Driven Development or Test Driven Development) easier than ever before. However, if you want to use VS 2008 as a fully-integrated TDD environment, you'll need to make creative use of the Task List.

Test Driven Design and Development

The idea behind TDD is that you write all the code for your application through a series of small steps by creating unit tests. The mantra is, "Never write a single line of code unless you have a test that fails." There are a couple advanatages to doing it this way:

• By doing things in small steps, you can go quicker with less errors
• You create unit tests as you go and rerun them with each coding change, immediately finding any code that gets broken when you add new features

So how do you start?

Like any software project, TDD starts with requirements. What does the software need to do? You take each requirement and generate a "test list," a list of all the criteria that must be met to fulfill the requirement.

The basic TDD process is Red/Green/Refactor:

1. Write a test that fails so that the unit test shows a red light
2. Add code to make the test pass and show a green light
3. Refactor to avoid duplication

Using Visual Studio as TDD Environment

Visual Studio now helps with this process. Visual Studio 2008 Professional Edition now includes the Visual Studio Test Suite (previously only Team Edition had it) which gives you the red and green lights. The Visual Studio editor also includes some built-in refactoring support.

However I would like to do everything within a single IDE if possible. I would prefer to do the Test Lists within my code editor rather than entering them into a spreadsheet, text file, or writting them down on paper. One way to do this is with the Visual Studio Task List.

Visual Studio Task List

The Task List has been part of VS since the original .Net 1.0 release. It provides a mechanism for reminders of things that developers need to complete.

You can open the Task List by selecting it from the View menu. There are two types of tasks: User and Comments. User tasks are things that you enter manually and manage yourself. Comments are created by adding comments with special key words to your code. You can then jump from your task list to the spot in the code where you put the comment.

Visual Studio provides three default tokens for comment tasks:

• TODO: Something that needs to be started or completed. VS will automatically generate some of these, for example when you create a new class it adds, "TODO: Add constructor logic here."
• HACK: Quickly written code that needs to be reworked later.
• UNDONE: Code changes that have been reversed.

To create a comment you enter the comment characters, (// in C#, ' in VB), the token followed by a colon (:) and the text of the task.

We can use the Task List for TDD by adding our own comment token: TEST.

To add a custom token we select options from the Tools menu and then select Task List under Environment:

To add our new token we enter TEST in the Name field and then click Add. We can now add a Test Task anywhere in our code by starting a comment, typing TEST: and a description of our test. Now you can create your TDD test list right inside the VS source code editor for your test project.: // TEST: Verify a user can add a new record // TEST: Verify a user can update an existing record // TEST: Verify a user can delete an existing record // TEST: Verify an error occurs when add a duplicate record To implement each test you add your test code after the comment and delete the TEST: part of the comment to remove the test from the Task List:

// Verify a user can add a new record [TestMethod()] public void AddNewRecord() { // TODO: Add Test Logic }

As you think of new tests while your in the middle of coding others you add a TEST: comment and then go back to what you're working on. Later, you can double-click on an item in the Task List to go directly to that spot in the code.

In my next blog post I'll walk you through a simple example.

Happy not to be Spam

This is first cold morning of the season here in Colorado. I'm sipping my Starbuck's pumpkin spice latte and rejoicing that my blog has been cleared by the Blogger spam cops. You see, soon after I posted my first entry I received an email saying, "Your blog has been identified as a potential spam blog. To correct this, please request a review by filling out the form [here]." I checked my blog this morning and it's all back to normal again. I've been approved. Now that I've been approved, where do I start? Yesterday a was a bit of downer at work. It was the last day for several of the contractors because the company I work for is feeling the credit crunch and economic downturn that is dominating the news now. Last week was the "worst week in stock market history." I've heard that before. The economy goes in cycles. We're near the bottom now, there's brighter days. It's just hard to believe it at the moment, but we can ride the coming bull market to success. After working in IT for 20 years I've come to accept the fact that software developers are an expense that every business needs to minimize in order to be successful. The key to success as a programmer is to be a partner with your employers to deliver the highest quality software at the lowest cost possible. Today we have many tools and methodologies to help achieve that goal. In future blog posts I will be covering things like the newest versions of languages and developer tools, Test Driven Development, MVC, agile development, combining it all together into the "Get 'er Done" methodology.

Finally starting to blog

Hi, My name is Ray Wampler and this is my first blog. Why would anyone want read a blog by me? There are a few areas where I have some expertise that other people might find interesting:

• I've worked in the IT/Software industry for over 20 years for a variety of companies and industries. I keep up on the latest technologies and trends.
• I've been in Toastmasters for 8 years, earning the distinction of Advnaced Communicator Silver and Advanced Leader Silver, and I'm currently working on my Distinguished Toastmaster.
• I keep informed on a variety of topics including health and nutrition, travel, volleyball, business, and investing.

These subjects will hopefully provide a wealth of topics for interesting and entertaining blog posts. I plan to add to this blog on a regular basis, providing usefull information to my readers.

Regards,

Ray Wampler