Frictionless Testing with TestDriven.NET

Much has been written in the last several years about the benefits of unit testing and test-driven development. The basic idea is that you should write a test for every bit of functionality in your application, and exercise these tests as you go along to make sure that you didn't break anything. Proper use of these techniques can lead to increased confidence and fewer errors in your code. A number of tools, such as NUnit, MbUnit, and even (for those of you brave enough to run the Visual Studio 2005 beta) Microsoft Team System now support unit testing for .NET development. But a new entrant to the .NET ecosphere, TestDriven.NET, makes the process easier than ever. In this article, I'll show you how.

Writing and Running Your First Test

Other tools, such as NUnit, run as external applications. They test your code outside of the IDE. TestDriven.NET, in contrast, hooks unit testing directly up to Visual Studio .NET. It can also make use of any of the testing frameworks I've already mentioned; it comes with a bundled copy of MbUnit, so that's what I'll use here. To get started, download a copy of TestDriven.NET and install it. The download is free, although you do need to register with the site to get it. Then create a new Visual Basic .NET class library project using Visual Studio .NET 2003.

The simple project I'll develop will let callers determine some properties of numbers. I've added two classes to the project: Number.vb, which will contain the actual code for the class, and NumberTests.vb, which will contain test code. To see the mechanics of TestDriven.NET, I'll start with a simple implementation of Number. The first thing this class needs to do is to be able to set the value of the number and retrieve it. Here's a skeleton that defines the proper interface:

Public Class Number

    Public Sub New()

    End Sub

    Public Property Value() As Integer
        Get

        End Get
        Set(ByVal Value As Integer)

        End Set
    End Property

End Class

You're probably looking at that code and thinking that there's no way that it could possibly work - and you're right. But one of the tenets of test-driven development is to write tests before you write code. That way you can be sure you know why you're writing each bit of code. So, let's move on to write a test.

Because I'm going to use MbUnit for the actual testing, I need to add references to MbUnit's two libraries: MbUnit.Core.dll and MbUnit.Framework.dll. These libraries get installed to the MbUnit folder beneath the TestDriven.NET install location. With the MbUnit objects available, it's time to write the start of the test class:

Imports System
Imports MbUnit.Core.Framework
Imports MbUnit.Framework

 _
Public Class NumberTests

     _
    Public Sub TestValue()
        ' Make sure we can store and retrieve a value
        Dim num As New Number
        num.Value = 5
        Assert.AreEqual(num.Value, 5)
    End Sub

End Class

MbUnit, like the other .NET unit-testing frameworks, uses attributes to carry metadata. The TestFixtureAttribute attribute indicates that this class contains tests. The Test attribute on the TestValue method indicates that this method is a unit test. This particular test instantiates a Number object, sets its value, and then tests the value using the MbUnit Assert object. If the two arguments to the AreEqual method are the same, the test is a success; otherwise, it's a failure.

Now it's time to see how easy it is to run a test using TestDriven.NET. Right-click in the test class and select Run Test(s). TestDriven.NET will compile the project, find the appropriate tests, run them, and display the results in the Visual Studio .NET output pane. In this case, the output ends with the ominous warning:

0 succeeded, 1 failed, 0 skipped, took 0.00 seconds

Yes, the test failed (which is hardly surprising, because the Value property is only partially implemented). Even better, MbUnit saves its output as an HTML file, and TestDriven.NET obligingly provides a link to this file in the output pane. Control-click the link to open the output report right in the IDE, as shown in Figure 1. As you can no doubt guess, the unhappy red colors indicate that not all is well here.

Click here for a larger image.