Assertions
Earlier in the tutorial I described the Arrange, Act, Assert (AAA) pattern that is often applied to unit tests. The arrange part describes the preparation of objects and data prior to testing. The act section of a test is where the activity being tested is executed. In the assert stage the results of the actions are tested, in most cases using assertions.
When using NUnit, most assertions are defined using static methods from the Assert class. Each method describes the expected state of an object or value and receives the actual value during test runs using a parameter. If the assertion is met, the testing continues with the next line of code. If the assertion fails, an exception is thrown and the test method exits without processing any further assertions. The thrown exception is caught by the test runner and displayed as a failure. Many other testing frameworks use a similar process.
NUnit provides many different types of assertion. In this article we will consider equality asserts. Over the course of the next six articles we will review further common Assert methods.
Equality Asserts
Probably the most commonly used assertions are the equality assert methods. These allow you to determine if two items have the same value or not. If you are testing an algorithm that has a predictable result, you will generally execute the algorithm with known input values and compare the result with the expected value using an equality assert.
Assert.AreEqual
The AreEqual assertion compares two values to determine if they are equal. The method accepts two parameters. The first holds the expected value for the test. The second accepts the actual value, which is generally held in a variable generated in the act stage of the AAA pattern. For simpler tests you may perform the act action within the parentheses of the method.
The code below shows a simple class with a method that adds two values. The test fixture tests the addition by creating a new Adder, executing the method and comparing the result with the expected value. NB: The test fixture and code under test are shown together for simplicity. In a real solution these should be in separate projects.
public class Adder
{
public int Add(int a, int b)
{
return a + b;
}
}
[TestFixture]
public class AdderTests
{
[Test]
public void OnePlusTwoEqualsThree()
{
Adder adder = new Adder();
int result = adder.Add(1, 2);
Assert.AreEqual(3, result);
}
}If the above Add method included a bug, when the test failed you would see the class name, the expected value and the actual value in the test runner. In the graphical test runner the result is as shown below:
Example_Tests.AdderTests.OnePlusTwoEqualsThree:
Expected: 3
But was: 1
If your test fixture classes and methods are named well this message can be enough to identify the problem quickly. However, to supply more information you can add an extra argument to the assertion. This parameter accepts a string containing a message to display when the test fails. For example, the Assert.AreEqual call could be updated as follows:
Assert.AreEqual(3, result, "Adder.Add should perform simple addition");
Now when the test fails the output includes the new message:
Example_Tests.AdderTests.OnePlusTwoEqualsThree:
Adder.Add should perform simple addition
Expected: 3
But was: 1
Assert.AreNotEqual
The reverse of AreEqual is AreNotEqual. This has fewer uses than AreEqual as it is more likely that you want to test that a value is equal to something, rather than checking that the result of an action is not equal to a given value. The following code shows a sample call, though the use in this circumstance is questionable.
[TestFixture]
public class AdderTests
{
[Test]
public void OnePlusTwoIsNotFour()
{
Adder adder = new Adder();
int result = adder.Add(1, 2);
Assert.AreNotEqual(4, result);
}
}2 April 2011