NUnit

NUnit. Chances are that you know what NUnit and Test Driven Development are, but if you don’t I’ll give you a quick primer. Test Driven Development means that you drive your development from tests. I know I just reversed the order of the words, but lets take a look at what that means 😉 Test Driven Development has a little motto that goes, “Red. Green. Refactor”.

The red refers to writing the tests for what you want your code to do before you write the code to do it. When a test fails in NUnit (and other Testing Frameworks), they show up as red. Next, you write the actual functional code to make the test pass (green), and then you refactor the code so it is as clean, extendable, testable, and maintainable as possible. Then you run the tests again to make sure that none fail. If they do, you fix your code so that the tests can pass again. You repeat this process as much as is prudent for the project that you are on.

The extra added benefit is that you can feel safe in making changes to your code later. If you have written sufficient test coverage, you can run your tests and if they all pass, then your changes will cause no problems when you deploy.

Now, on to NUnit. NUnit is the first unit testing framework that I ever heard of or used, so I have a soft spot for it. You can get started by downloading NUnit from their download page here. The easiest way to get going quickly is to pick the download named NUnit-2.4.8-net-2.0.msi and then just run the install wizard.

Once you have everything installed, let’s get started. For a sample, let’s just make a new C# class library project called NUnitExample. Add a reference to nunit.framework.dll that can be found at (if you accepted the defaults on install) at C:\Program Files\NUnit 2.4.8\bin\nunit.framework.dll.

Now, enter the following code into the default Class1.cs file and build the project:

using System;
using NUnit.Framework;

namespace NUnitExample
{
    /// <summary>
    /// [TestFixture] is an attribute that you 
    /// add above any class that you want to 
    /// contain tests.
    /// </summary>
    [TestFixture]
    public class MathTests
    {
        protected int a;
        protected int b;
        protected int c;

        /// <summary>
        /// Any variable setting or state 
        /// setup you need to do can be done
        /// in a method marked with the 
        /// [TestFixtureSetUp] attribute.
        /// </summary>
        [TestFixtureSetUp]
        protected void Setup()
        {
            a = 9;
            b = 2;
            c = 0;
        }

        /// <summary>
        /// You can create tests by applying 
        /// the [Test] attribute to any method 
        /// that is public, takes no params, 
        /// and returns void. If the method 
        /// does not meet these requirements, it 
        /// will be ignored.
        /// </summary>
        [Test]
        public void Adding()
        {
            Assert.AreEqual(11, a + b);
        }

        /// <summary>
        /// This Test will fail. Normally, you test for purposeful failure 
        /// (like a validation error) and that is a "passed test", that 
        /// isn't what I'm doing here.  I'm just showing what a failed test 
        /// looks like in the Test Runner.
        /// </summary>
        [Test]
        public void Dividing()
        {
            Assert.AreEqual(4.5M, a / b);
        }

        [Test]
        public void DivideByZeroException()
        {
            try
            {
                int x = a / c;

                // If we get to this line, throw an 
                // exception because the above division 
                // shouldn't work.
                throw new Exception("Division Worked");
            }
            catch (Exception ex)
            {
                Assert.IsInstanceOfType(typeof(DivideByZeroException), ex);
            }
        }

        [Test]
        public void Comparison()
        {
            Assert.That(a > b);
        }

        /// <summary>
        /// These next 3 tests will be ignored 
        /// because their signatures aren't 
        /// correct.
        /// </summary>
        [Test]
        private void Ignored1()
        {
            Assert.AreEqual(1, 2);
        }

        [Test]
        public string Ignored2()
        {
            Assert.AreEqual(1, 2);
            return string.Empty;
        }

        [Test]
        public void Ignored3(int a, int b)
        {
            Assert.AreEqual(1, 2);
        }
    }
}

Now, fire up the NUnit Test Runner GUI. It is located at C:\Program Files\NUnit 2.4.8\bin\nunit.exe. When it opens, click File –> Open Project and then navigate to the .dll that was created from the project that you built and click “Open”.

The NUnit GUI should now look like this:

Make sure you have the top level highlighted and click Run. It will look like this:

What you see is that the entire test fixture of NUnitExample has failed (the red circle with the X). Parent levels are always shown as having the same success level as the lowest success level below it. You see that Adding, Comparison, and DivideByZeroException passed. No surprise here. Additionally, the three tests named ignored have been ignored because their signatures were incorrect. If you click the “Tests Not Run” tab at the bottom of the runner, you can see why.

If you click the “Errors and Failures” tab, you will see why the Dividing Test failed.

NUnitExample.MathTests.Dividing:
  Expected: 4.5m
  But was:  4m

Oh, yeah. Integers only hold whole numbers. Lets go back and change the code. (Normally, you’d change your code, but here the “active” code is embedded in the tests because of this simple sample.) Change the Dividing test to the following:

public void Dividing()
{
    Assert.AreEqual(4.5M, Convert.ToDecimal(a) / b);
}

When you switch back to the NUnit Test Runner, it will have automatically refreshed because the test project has changed. Run it again and the Dividing test will pass and the overall status will be yellow because the lowest level of success in the child tests was also yellow.

If you instead would like to use the command line for NUnit (perhaps for continuous integration or just as part of your build task on your program) you can do that as well. Open a command window and enter the following command: (If you changed anything on NUnit install, change “c:\Program Files\NUnit 2.4.8\bin” to match your install path. The argument passed in is the path to the .dll of the project that you created.)

"c:\Program Files\NUnit 2.4.8\bin\nunit-console" c:\code\blog\NUnitExample\NUnitExample\bin\Debug\NUnitExample.dll

When you run it, you get the following results:

c:\Program Files>"C:\Program Files\NUnit 2.4.8\bin\nunit-console" C:\Code\Blog\NUnitExample\NUnitExample\bin\Debug\NUnitExample.dll
NUnit version 2.4.8
Copyright (C) 2002-2007 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.

Runtime Environment -
   OS Version: Microsoft Windows NT 6.0.6001 Service Pack 1
  CLR Version: 2.0.50727.1434 ( Net 2.0.50727.1434 )

.....N.N.N
Tests run: 4, Failures: 0, Not run: 3, Time: 0.031 seconds

Tests not run:
1) NUnitExample.MathTests.Ignored1 : Method Ignored1's signature is not correct:
 it must be a public method.
2) NUnitExample.MathTests.Ignored2 : Method Ignored2's signature is not correct:
 it must return void.
3) NUnitExample.MathTests.Ignored3 : Method Ignored3's signature is not correct:
 it must not have parameters.

In a later post, I will look at doing Test First development with a true “Red. Green. Refactor.” feel.