What Is a Test Harness?

Because writing class libraries is a big part of any developer's job, it follows that testing class libraries is a big part of your job, too. Testing an application, whether it's a Windows application or a Web application, is relatively straightforwardyou run it, and experiment with various paths through the application in terms of which buttons you click, or which fields you fill out or leave blank. But how do you test a class library, or a service, or even a single class that encapsulates an important business process or set of rules?

Console applications are perfect for this kind of testing. They are quick to write, and you don't need a fancy user interface. In fact, it's easy to capture the output of a console application by redirecting it to a file. This enables you to save the results of test after test and compare them. Windows programmers aren't always familiar with the techniques for interacting with users without using controls, but they're quick to learn and definitely useful.

A test harness for working with a single class is the simplest to write. Typically it should perform the following steps:

• Create an instance of the class. If there are several constructors, create several instances.

• Use any Display() or Report() method of the object to show its contents after creation.

• Exercise each method and property of the class, and display the results of each call or the contents of the object after the call.

• If methods must be called in the right order, have some code that calls them in the right order and also some code that calls them in the wrong order, to confirm that error-checking code works.

• If the methods throw exceptions, set up calls that will fail and surround them with try and catch blocks to prove that the correct exceptions are thrown.

• If you have written a copy constructor or conversion operator for the class, write code that will use them and display the contents of all affected objects to demonstrate successful copying or conversion.

• If the object has a clean-up method such as Dispose() , call it and prove it was called.

• If the object is not garbage-collected , let it go out of scope or delete it to prove that the destructor works correctly.

It's a good idea to have lots of output statements sprinkled throughout this code, so that output might look something like this:

 Creating account1, default constructor Account # 123, Balance 
 Creating account1, default constructor Account # 123, Balance $0.00 Creating account2, passing 50 Account #124, Balance $50.00 Deposit 100 to account1 Account #124, Balance $100.00 
 .00 Creating account2, passing 50 Account #124, Balance .00 Deposit 100 to account1 Account #124, Balance 0.00 

This sort of output demonstrates which parts of your code are working and serves as an excellent record of the development process. Generally, all of the values are hard-coded so that you can run the whole thing without having to interact with it, but some people write test harnesses that prompt for values or even for which methods to exercise.

When your test harness is testing a component or a layer, your tests will typically interact either with a single bridging class that provides access to the functionality of the component or layer, or with each of the classes in the component or layer. This can make the harness quite long, but a systematic test of all your functionality is well worth doing, so take the time.