ToolKit
LANGUAGES: All .NET Languages
TECHNOLOGIES: .NET Attributes
Find and Fix Bugs With NUnit
Test your business logic with this structured API.
By Ken McNamee
Arguably, the most important step in professional software development is the testing phase. I'm not talking about load testing, although that is a critical step as well. I'm talking about testing the classes and methods that implement your business logic to ensure they function the way you intend and return the correct results. If you know a method should return a Boolean value of true but it returns false instead, that's certainly a problem you need to address. NUnit is a tool that gives you the power to find these bugs and address them while in the development phase rather than during QA or production.
NUnit has two components: the NUnit Framework API you use to create the testing assembly, and the Windows Forms application you use to run the testing assembly and display the results. Take this class for example:
public class Math {
public static int Divide(int a, int b) {
return a / b;
}
}
This is about as simple as it gets, but it will work well for this example. To verify that the Add method can add two integers correctly, you must first create another class to test it. You can create this class in the same source-code file as the class you're testing, or in a different file, project, or even namespace. Here is what the test class for the Math.Divide method looks like:
[TestFixture]
public class MathTest {
[Test]
public void DivideTest() {
int result = Math.Divide(4, 2);
Assertion.AssertEquals(2, result);
}
}
The first thing you might notice is the [TestFixture] class attribute and the [Test] method attribute. When the NUnit GUI application reflects on the compiled assembly, it uses these attributes to know which classes and methods to run. The previous version of NUnit requires that the test class inherit from a TestCase class and that the names of the methods running the tests begin with a "Test" prefix. These are no longer requirements because the NUnit developers have moved on to an attribute-based system that is more elegant, flexible, and intuitive.
The key line of code in the DivideTest method is the one calling Assertion.AssertEquals. The first parameter passed in represents the value the Math.Divide method must return for it to work correctly and for the test to pass. AssertEquals simply compares that value with the one in the second parameter, which is the result variable. Again, this is a fairly simple example but it demonstrates the simplicity of NUnit adequately. You can take what I've shown so far and get an enormous return on your investment in NUnit and, because NUnit is open-source and free, the only investment required is a little bit of your time.
In addition to testing the values returned from your methods, you also can verify that exceptions you would expect to be thrown under certain circumstances are indeed thrown. This is an important point because your application might depend on certain code being run within a particular catch block. You could rewrite the DivideTest method like this:
[TestFixture]
public class MathTest {
[Test]
[ExpectedException(typeof(DivideByZeroException))]
public void DivideTest() {
int result = Math.Divide(4, 0);
}
}
The ExpectedException attribute tells NUnit that this call to Math.Divide must throw a DivideByZeroException in order for this test to pass. This is a convenient capability and an example of a test that would certainly be possible to duplicate using your own testing mechanism. Yet, this is not necessary because NUnit provides this ability. If the ExpectedException attribute were missing from this code, you would see something similar to Figure 1 when you run the test.
Figure 1. Not telling NUnit which exceptions to expect results in a test
failure.
NUnit provides an easy, consistent framework for testing your code, thus negating the need to develop your own testing mechanism. The fact that it's also free and open-source makes its use - in my humble opinion - a no-brainer. Verifying the soundness of your business logic and the integrity of its results should be a frequent and well understood step in your everyday development workflow. This process is sometimes painful, so I believe you should consider any solution that can make it easier and more successful, perhaps implementing it on a trial basis. I strongly recommend that you download NUnit and make a wholehearted effort to integrate it into your development process. Change can be difficult, but the long-term gains in productivity and code quality far outweigh any short-term grief.
The sample used in this article is available for download.
REFERENCES
NUnit home page: http://nunit.org
NUnit at SourceForge: http://sourceforge.net/projects/nunit
Ken McNamee is a senior software engineer with RelayHealth Corp., a provider of secure, Web-based services for doctor-patient communication. Prior to this, he led a team of developers in rebuilding the Home Shopping Network's e-commerce site, HSN.com, to 100 percent ASP.NET with C#. E-mail Ken at mailto:[email protected].
Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.
