Migrating from NUnit to csUnit

Introduction - Programming Language - Prerequisites - TestFixtures - Test Methods - SetUp and TearDown - Ignoring A Test Or A Test Fixture - Expected Exceptions - Test Suites - Assertion - Summary - Credits

by Jake Anderson

Introduction

In this document you will find the necessary information for migrating from NUnit version 2 to csUnit version 1.7. We are providing this information as a curtesy to our users who are in need of this migration, or want to use their existing unit testing code in a new unit testing framework. The contents of this document represent a culmination of user feedback and the personal experiences of the csUnit development team. If you wish to contribute to this working document, please send your experiences to either the csUnit discussion group or to the csUnit project team.

Programming Language

The tutorial uses C#.

Prerequisites

This tutorial makes the following assumptions:

• Visual Studio .NET and csUnit 1.7.3 or later are installed
• You have a project that currently works with NUnit version 2.0 (as of April 15, 2003) and conforms to their published guidelines.

TestFixtures

Both NUnit and csUnit use the [TestFixture] attribute in your source to identify a unit testing class. Remember that your test class must be public and it must have a constructor that takes no arguments.

The following is a sample unit test class, i.e. TestFixture:

using System;
using csUnit;

namespace example {
    /// <summary>
    /// Summary description for FooTests.
    /// </summary>
    [TestFixture]
    public class FooTests() {
       public FooTests() {
          //
          // TODO: Add constructor logic here
          //
       }
    }
}

The TestFixture attribute takes no parameters and can be applied to classes only. It serves only identification purposes. Upon loading the assembly csUnit searches the entire assembly for classes with this custom attribute set. Don't forget to add a reference to the csUnit assembly to your projects references, and also add the using directive to the source code (see sample above).

NOTE - The [TestFixture] attribute is not passed down in the inheritance chain for test classes in csUnit 1.7. This is in contrast to the behavior known in NUnit, where the [TestFixture] attribute is inherited. If you have specialized test fixtures, then you will need to add [TestFixture] to their class definition to make them recognized by the csUnit 1.7 framework.

Test Methods

The next step is to migrate your test methods. NUnit identifies its test methods the same way in which csUnit does, either by the method name starting with 'test' (case insensitive), or by way of the [Test] attribute.

The following is an example of defining test methods in the csUnit framework:

using System;
using csUnit;

namespace example {
    /// <summary>
    /// Summary description for FooTests.
    /// </summary>
    [TestFixture]
    public class FooTests() {
       [Test]
       public void MyFirstTest() {
          // your test implementation goes here
       }
    }
}

Like NUnit, csUnit only runs public void test methods. Even if you attempt to apply the [Test] attribute to a non-public void method, it will not run that method.

SetUp and TearDown

The [SetUp] and [TearDown] attributes assigned to your NUnit test methods will translate without change to csUnit. Methods defined as such will be run before and after the execution of each and every Test method in a TestFixture.

The following is an example of using these two attributes in a TestFixture:

using System;
using csUnit;

namespace example {
    /// <summary>
    /// Summary description for FooTests.
    /// </summary>
    [TestFixture]
    public class FooTests() {
       [SetUp]
       public void SetUp() {
          _myTestData = new TestData();
       }

       [TearDown]
       public void CleanUp() {
          _myTestData.Dispose(); // assumes IDisposable is implemented
          _myTestData = null;
       }

       [Test]
       public void MyFirstTest() {
          // your test implementation goes here
       }

       private TestData _myTestData = null;
    }
}

Again, the signature of both, the SetUp and the TearDown methods must be public void.

Ignoring A Test Or A TestFixture

The [Ignore] attributes that you already have defined in your NUnit test classes will be understood by the csUnit framework without modification. The csUnit's [Ignore] attribute takes a single parameter as its output message.

The following is an example use of the [Ignore] attribute:

using System;
using csUnit;

namespace example {
    /// <summary>
    /// Summary description for FooTests.
    /// </summary>
    [TestFixture]
    public class FooTests() {
       [Test]
       public void MyFirstTest() {
          // your test implementation goes here
       }

       [Test, Ignore("Implementation not complete yet.")]
       public void SkipThisOne() {
       }
    }
}

using System;
using csUnit;

namespace example {
    /// <summary>
    /// Summary description for FooTests.
    /// </summary>
    [TestFixture]
   [Ignore("Fixture is of no use yet")]
    public class FooTests() {
       [Test]
       public void MyFirstTest() {
          // your test implementation goes here
       }
    }
}

If the Ignore attribute is put on a test fixture, it will not even be instantiated during running the tests. csUnit accesses only the type information including the custom attributes for the test fixture and the tests contained in it.

Expected Exceptions

Version 1.7 of csUnit does not support the [ExpectedException] attribute.

Assertion

Probably the most work that you will encounter in migrating from NUnit to csUnit is in the use of the Assertion. NUnit's assert methods are implemented in the Assertion class and have names such as AssertEquals. The csUnit equivalent is to use the Assert class members, such as Assert.Equals.

Previous versions of csUnit (prior to 1.7) supported a nomenclature such as Assert.AssertEquals which follows the namenclature of NUnit's Assertion class. These methods are now deprecated in csUnit and will be going away in future releases. You can use these methods with version 1.7, but they will generate compiler warnings.

NUnit also provides a string argument to its assertion methods, which is echoed to the test report when an assertion is triggered. csUnit does not provide this type of feature, except in the Assert.Fail method.

Test Suites

csUnit does not support a TestSuite class as it exists in the NUnit framework. To run multiple test classes, csUnit reads from a recipe file that contains the names of the assemblies from which test classes are loaded.

As of version 1.7, there is no functional equivalent to the TestSuite attribute found in NUnit.

Summary

Credits

Portions of this document were taken from correspondence with John R. Pierce. Thank you very much Mr. Pierce for your contribution.

Portions of this document describing the NUnit API are copyrighted by the NUnit project team.

csUnit is sponsored by: csUnit is also hosted on (but not sponsored by):

Copyright © 2002-2003 by Manfred Lange, All rights reserved. Last change: 4/16/2003.