.NET 1.1+

Creating Unit Tests

by Richard Carr, published at http://www.blackwasp.co.uk/CreatingTests.aspx

The third part of the Automated Unit Testing tutorial examines the construction of unit tests using the NUnit testing framework. This article describes the use of the attributes that determine how the test runner executes unit test code.

NUnit Attributes

In the previous article in this tutorial I described some basic tests created and executed using the NUnit testing framework. In this article we will examine the structure of the unit test code further, concentrating on attributes that are used to identify sections of code as tests or as methods that prepare objects for testing and clean up after tests are executed. As before, the syntax described is specific to NUnit. However, the techniques are similar to those used in most popular .NET testing frameworks.

To keep the examples in the article as simple as possible, we will run tests using existing classes and structures from the .NET framework. It is likely that there would be no reason for you to test .NET classes in reality but this will allow us to concentrate on the tests rather than the code under test. To begin, create a new class library project. To provide easy access to the NUnit framework, add a reference to the nunit.framework.dll assembly and include the following using directive in all source code files containing tests:

using NUnit.Framework;

A Simple Test

All tests use the same underlying structure. Firstly you must create a test fixture. This is a container that can hold a single test or a group of related tests. When using NUnit, a test fixture is a class that is decorated with the TestFixture attribute. The class must be declared with a public scope and must be concrete, not abstract. NUnit creates instances of test fixture classes using the default constructor so this must be present, either by being defined explicitly or by the test fixture containing no constructors. The test runner may instantiate the class several times so the constructor should have no side-effects. It is advisable in most cases to omit constructors from the class entirely.

Within a test fixture class you create one or more tests. Each test is a public method that is decorated with the Test attribute. In order that the test is executed the method must have the correct signature. It should have no parameters and a void return value.

Each unit test should exercise a small section of the code under test. Usually a test will include an assertion, which specifies an expected value after the code is executed. Assertions are defined using static methods from the Assert class. Various types of assertion will be described in a later article in the series.

To create a simple test, add the following class to the project.

[TestFixture]
public class SimpleTestFixture
{
    [Test]
    public void TwoTimesTwoEqualsFour()
    {
        Assert.AreEqual(4, 2 * 2);
    }
}

The above class is a test fixture named SimpleTestFixture. It contains a single test, named TwoTimesTwoEqualsFour. The name of the method describes the purpose of the test. In this case we are using the Assert.AreEqual method to define an assertion. The first argument of the method specifies that we expect a value of four. The second argument provides that actual value for comparison. In this case the value is the expression, 2*2. If the values match and the method exits normally, the test runner will indicate a successful test. If the two values do not match or an exception is thrown during execution, the test fails.

Arrange, Act, Assert

The above example test is far more simplistic than tests you will usually create, as it only includes an assertion. Most tests should follow the Arrange, Act, Assert (AAA) pattern. Tests structured using AAA have three well-defined areas. The first part of the test is the Arrange step. Here you prepare the objects and data that are required for the test. The Act step contains the behaviour that is being tested. The Assert step provides the assertions that will prove that the code is working as expected or identify problems.

Structuring tests with the AAA style can make it easier to read and maintain the tests later. Some developers like to add a comment to each step, highlighting which stage each line of code belongs to and as a reminder to keep to the pattern. I will add these comments in this article so that you can see their usage.

The following sample shows a slightly more complicated test that checks that two words are combined correctly by the String.Format method. The Arrange portion prepares two source strings. The Act section contains the String.Format command, which is the item under test. Finally, the Assert step tests that the result of the operation is as expected.

[TestFixture]
public class ArrangeActAssert
{
    [Test]
    public void CombiningWordsWorksCorrectly()
    {
        // Arrange
        string word1 = "Hello";
        string word2 = "World";

        // Act
        string phrase = string.Format("{0} {1}", word1, word2);

        // Assert
        Assert.AreEqual("Hello World", phrase);
    }
}