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 (with some hints regarding csUnit 1.8.6). We are providing this information as a courtesy 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 2002/2003 and csUnit 1.7.3 or later are installed. Alternatively, you may also use csUnit 1.8.6.
• 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. With csUnit 1.8.5 Beta or later the attribute [TestFixture] is also inherited.

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. Support for expected exceptions is available for csUnit 1.8.6 or later.

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, which in turn followed the way JUnit works. 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 1.7 does not provide this type of feature, except in the Assert.Fail method. In csUnit 1.8.6 all assertion methods are also available in a version including a string argument.

Test Suites

NUnit provides two ways for defining test suites: either through the attribute [TestSuite] or by using namespaces.

csUnit 1.7 does not support test suites at all. Instead it supports loading multiple assemblies, each of them could be looked at as a test suite. Sets of assemblies can be saved as recipe files for later reuse.

csUnit 1.8.6 or later adds support for namespaces treated as test suites. Namespaces are no longer flattened out.

Summary

The following table lists the similarities and differences between NUnit 2, csUnit 1.7, and csUnit 1.8.6. This table only provides information that is relevant to migrating NUnit test cases over to csUnit's framework. Additional information about the features available in csUnit can be found in the features section.

Happy Testing!

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.

Home

Download

Documentation

Features

Tutorials

Support

Suggest A Feature

Report A Bug

About

Sponsors:

Copyright © 2002-2008 by Agile Utilities NZ Ltd. All rights reserved. Site design by Andreas Weiss. This site is protected by bot traps.