Converting NUnit Unit Tests into Tests Compatible with Visual Studio 2005 Team System

Installation. 4

Quick Start 5

Differences. 13

Software License. 27

NUnit (http://nunit.org) is a unit testing tool for the .NET Framework. It is currently at version 2.2.8 and it has been in use since early 2001. Visual Studio 2005 Team System introduces a similar capability which is integrated into the Team System suite of tools. The unit testing support is in the Developer and Test versions of Visual Studio 2005 Team System. This tool will assist in the migration of existing NUnit tests into test code compatible with Visual Studio.

Note: The conversion is not 100% compatible. There are differences that exist between the two testing tools. Some of these can be figured out by the converter and the code adapted to work, others cannot. In all cases the converted code should compile in Visual Studio but there may be instances where the converted tests will not run. These tests will require manual intervention on your part to complete the conversion process.

Installation

1. Unzip the nunitconversion.zip package

2. Install NUnit-2.2.4-net-2.0.msi

The tool has only been tested against NUnit 2.2.4, if you have a later version of Nunit installed you may want to downgrade to Nunit 2.2.4.

3. Install the Guidance Automation Extensions (GAX) February 2007 CTP before moving on to the next step.

4. Install the Guidance Automation Toolkit February 2007 CTP before moving on to the next step.

5. Right click on NunitConversionSetup.bat and choose run as administrator.

6. Follow the MSI installation instructions. One caveat: It has not been tested in any other directory than the default directory. This of course does not mean it will not work in a different directory it just means that it might not. Also the rest of the instructions assume you have put it in the default directory. You can think of this as a strong hint to leave it in the default directory.

7. Start Visual Studio 2005 Team System.

8. Open a solution file that has existing NUnit test code.

9. On the Tools menu, click Guidance Package Manager. A dialog box should open, see below. You should check to make sure that the “Convert NUnit Test Code” Recipe is present. Then click Close.

10. You have completed the installation.

Quick Start

The next step after installation has been completed is to convert some test code. The following instructions will walk you through this process step-by-step.
Note: You should always back up all your filesbefore running the converter. That way if you don’t like how the conversion process works you can always go back.

1. Back-up the files and their associated project and solution files. This step is critically important. There is no automated restore of your files back to a previous state.

2. Start Visual Studio 2005 Team System and run as Administrator.

3. On the File menu, navigate to New, click Project/Solution. Select C# Class Library project. Name the project BankingProject.

4. Rename class1.cs to Account.cs

5. Paste the following code into Account.cs:

using System;

using System.Collections.Generic;

using System.Text;

namespace BankingProject

{

public class Account

{

private float balance;

public void Deposit(float amount)

{

balance += amount;

}

public void Withdraw(float amount)

{

balance -= amount;

}

public void TransferFunds(Account destination, float amount)

{

if (balance - amount < minimumBalance)

throw new InsufficientFundsException();

destination.Deposit(amount);

Withdraw(amount);

}

public float Balance

{

get { return balance; }

}

private float minimumBalance = 10.00F;

public float MinimumBalance

{

get { return minimumBalance; }

}

public class InsufficientFundsException : ApplicationException

{

}

}

}

6. Right click on the solution and select Add New Item choose class library and use the name AccountTest.cs

7. Paste the following code into AccountTest.cs

using System;

using System.Collections.Generic;

using System.Text;

using NUnit.Framework;

namespace BankingProject

{

[TestFixture]

public class AccountTest

{

Account source;

Account destination;

[SetUp]

public void Init()

{

source = new Account();

source.Deposit(200.00F);

destination = new Account();

destination.Deposit(150.00F);

}

[Test]

public void TransferFunds()

{

source.TransferFunds(destination, 100.00f);

Assert.AreEqual(250.00F, destination.Balance);

Assert.AreEqual(100.00F, source.Balance);

}

[Test]

[ExpectedException(typeof(BankingProject.Account.InsufficientFundsException))]

public void TransferWithInsufficientFunds()

{

source.TransferFunds(destination, 300.00F);

}

[Test]

[Ignore("Decide how to implement transaction management")]

public void TransferWithInsufficientFundsAtomicity()

{

try

{

source.TransferFunds(destination, 300.00F);

}

catch (BankingProject.Account.InsufficientFundsException expected)

{

}

Assert.AreEqual(200.00F, source.Balance);

Assert.AreEqual(150.00F, destination.Balance);

}

}

}

8. Right click on the reference line and click on add a reference. Navigate to your NUnitV2 directory and go into the bin subdirectory. For me this directory is in “C:\Program Files\NUnit-Net-2.0 2.2.4\bin”. Select nunit.framework.dll and click OK.

9. Build the project by using the Build BankingAccount option in the Build menu. Make sure the build succeeds.

10. Start NUnit-GUI. You can find under your windows programs menu.

11. Go to the Debug folder for your project and select BankingProject.dll. Click Open.

12. Click Run. You’re Results should look like this.

13. We now have verified that the Nunit Tests work.

14. In Visual Studio. On the File menu, navigate to New, click Project. Select the appropriate (C# or VB.NET) test project and place it in the directory of your choosing. Name it BankAccountTesting. .

Tests must be in a Test Project

Visual Studio 2005 Team System requires that tests be contained in a separate test project. This means that if you had NUnit code in the same project with your production code that you will have to create a new test project and move the test code to the newly created test project.
Note: This has implications on the relationship between your test code and production code, especially with regard to visibility. If you had your NUnit test code in the same project than you could share internal access with other classes in that assembly. Since the Visual Studio 2005 Team System tool requires a separate test project you may have to alter the visibility of classes to allow the tests to compile and run. If you do not wish to do this you can consider using the new Assembly attribute: InternalsVisibleTo which is available in .NET Framework 2.0. For more information on InternalsVisibleTo see http://hoser.lander.ca/default,date,2005-11-21.aspx.

15. Copy each file that contains NUnit test code, in this case copy BankAccountTest, that you want to be converted into the test project. You can use the Add Existing Item option as well.

16. Add any required references (including a reference to NUnit) and compile the test project. Once the code compiles, run the tests in NUnit to ensure that you are starting with a working test harness. This step is optional but I like to do it because if the conversion process introduces problems, I know that I started with a working baseline.

17. Now onto the conversion process. Right-Click the test project BankAcountTesting in the Solution Explorer. Click the Convert NUnit Test Code. As each file is being converted it will be opened in Visual Studio. When the conversion is complete, the conversion results will be displayed.

If you don’t see Convert Nunit Test Code as an option please see Guidance Package Troubleshooting below.

If you get an access denied error or a path illegal error or a conversion error, it is likely that you are not running Visual Studio as an administrator. Close Visual Studio and run visual studio as an administrator.

The conversion is not 100% compatible. There are differences that exist between the two testing tools. Some of these can be figured out by the converter and the code adapted to work, others cannot. In all cases the converted code should compile in Visual Studio but there may be instances where the converted tests will not run. These tests will require manual intervention on your part to complete the conversion process.

Guidance Package Troubleshooting

If you don’t see “Convert Nunit Test Code” as an option it is likely that the guidance package is not enabled. Follow these smple steps to verify that the convertor package is enabled. Go to the Tools menu. Then select Guidance Toolkit Manager. Click the Enable/Disable package option. Put a check next to Nunit Test Code Conversion and click Ok. Click Close. Right-Click the test project BankAcountTesting in the Solution Explorer. Click the Convert NUnit Test Code.

If you still don’t see the convert unit Test Code Option, close and relaunch Visual Studio and run as an administrator.

18. The AccountTest class has now been converted to:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace BankingProject

{

[TestClass()]

public class AccountTest

{

static Account source;

static Account destination;

[TestInitialize()]

public void Init()

{

source = new Account();

source.Deposit(200.00F);

destination = new Account();

destination.Deposit(150.00F);

}

[TestMethod()]

public void TransferFunds()

{

source.TransferFunds(destination, 100.00f);

Assert.AreEqual(250.00F, destination.Balance);

Assert.AreEqual(100.00F, source.Balance);

}

[TestMethod(), ExpectedException(typeof(BankingProject.Account.InsufficientFundsException))]

public void TransferWithInsufficientFunds()

{

source.TransferFunds(destination, 300.00F);

}

[TestMethod(), TestProperty("Reason", "Decide how to implement transaction management"), Ignore()]

public void TransferWithInsufficientFundsAtomicity()

{

try

{

source.TransferFunds(destination, 300.00F);

}

catch (BankingProject.Account.InsufficientFundsException expected)

{

}

Assert.AreEqual(200.00F, source.Balance);

Assert.AreEqual(150.00F, destination.Balance);

}

}

}

19. Go to the Test Manager window and you will see the BankAccount Tests have been successfully converted.

20. Once you have completed the conversion process you should disable the guidance package. The reason is that every time you right-click in the Solution View the guidance package looks for NUnit test code. If there isn’t any to find it just wastes time. On the Tools menu, click Guidance Package Manager. A dialog box should open. Click Enable/Disable Packages. You should uncheck “NUnit Test Code Conversion”. Then click OK.

Differences

The following are differences that exist between the two tools from the perspective of someone who is currently writing their tests using NUnit. As I mentioned before some of these differences are handled by the converter and some are not.

.NET Framework 2.0

This probably does not need to be mentioned but Visual Studio 2005 Team System only supports projects that target .NET Framework 2.0.

Tests must be in a Test Project

Visual Studio 2005 Team System requires that tests be contained in a separate test project. This means that if you had NUnit code in the same project with your production code that you will have to create a new test project and move the test code to the newly created test project.
Note: This has implications on the relationship between your test code and production code, especially with regard to visibility. If you had your NUnit test code in the same project than you could share internal access with other classes in that assembly. Since the Visual Studio 2005 Team System tool requires a separate test project you may have to alter the visibility of classes to allow the tests to compile and run. If you do not wish to do this you can consider using the new Assembly attribute: InternalsVisibleTo which is available in .NET Framework 2.0. For more information on InternalsVisibleTo see http://hoser.lander.ca/default,date,2005-11-21.aspx.

New Instance per Test Method

One thing you need to take into account immediately is the different style in which Visual Studio 2005 Team System runs your tests. NUnit creates a single instance of a TestFixture class and runs all the Test methods in that single instance. Visual Studio 2005 Team System on the other hand uses a different approach. Instead of resuing one instance for all of the test methods, a new instance of the TestClass is created for each TestMethod contained in the class. This means that if you have 10 TestMethods in a TestClass than 10 instances of the class will be created when the tests are run. There have been arguments both pro/con on the two approaches. The New Instance per Test Method claims to be better at isolating the individual methods. However, since both approaches use classes this can be easily defeated by making all of your member variables static (C#) or shared (VB.NET). In fact that is exactly what the converter does. For example:

NUnit Code:

[TestFixture]

public class SetUpTests

{

private int value1;

private int value2;

[SetUp]

public void BeforeTest()

{

value1 = 2;

value2 = 3;

}

[Test]

public void Add()

{

int result = value1 + value2;

Assert.AreEqual(5, result);

}

}

Visual Studio 2005 Team System Code (converterd)

[TestClass()]

public class SetUpTests

{

private static int value1;

private static int value2;

[TestInitialize()]

public void BeforeTest()

{

value1 = 2;

value2 = 3;

}

[TestMethod()]

public void Add()

{

int result = value1 + value2;

Assert.AreEqual(5, result);

}

}

Note: The reason that the converter changes the variables to static is to preserve the existing behavior. This does not imply that you should use static variables in your new tests. Lastly, you may be able to change them back to instance variables.
Numerical Comparisons

The numerical comparisons work in most cases similar in both tools. However, there are instances in Visual Studio 2005 Team System when you compare values of different types that do not work as you might expect. For example,

NUnit Code

[Test]

public void Int32Int64Comparison()

{

long l64 = 0;

int i32 = 0;

Assert.AreEqual(i32, l64);

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod()]

public void Int32Int64Comparison()

{

long l64 = 0;

int i32 = 0;

Assert.AreEqual(i32, l64);

}

While the NUnit version of this test will pass, when the Visual Studio Team System test is run you will get the following result:

Failed Int32Int64Comparison Assert.AreEqual failed. Expected:<0 (System.Int32)>, Actual:<0 (System.Int64)>.

There is also a difference when comparing something against Double.NaN. Here is the NUnit test and the converted Visual Studio Team System test:

NUnit Code

[Test, ExpectedException(typeof(AssertionException))]

public void NanEqualsNaNFails()

{

Assert.AreEqual(Double.NaN, Double.NaN, 0.0);

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod(),
ExpectedException(typeof(AssertFailedException))]

public void NanEqualsNaNFails()

{

Assert.AreEqual(Double.NaN, Double.NaN, 0.0);

}

NUnit throws AssertionException when you compare Double.NaN to itself. Visual Studio Team System does not throw it’s similar exception which is called AssertFailedException. This may not occur in your test code very often. However it appears to be in direct conflict with the remarks sections of the Double.NaN documention which states the following:

· Use IsNaN to determine whether a value is not a number. It is not possible to determine whether a value is not a number by comparing it to another value equal to NaN.

TestFixtureSetUp and TestFixtureTearDown

This concept is also supported in Visual Studio 2005 Team System. The attribute names are ClassInitialize and ClassCleanup. The differences are that both methods ClassInitialize and ClassCleanup are static methods on the class and ClassInitialize takes a parameter of type TestContext.

NUnit Code

[TestFixture]

public class TestFixtureSetUpTests

{

private int context;

[TestFixtureSetUp]

public void BeforeClass()

{

context = 12;

}

[TestFixtureTearDown]

public void AfterClass()

{

// ...

}

[Test]

public void BeforeClassCalled()

{

Assert.AreEqual(12, context);

}

}

Visual Studio 2005 Team System Code (converterd)

[TestClass()]

public class TestFixtureSetUpTests

{

private static int context;

[ClassInitialize()]

public static void BeforeClass(TestContext
@__testContext)

{

context = 12;

}

[ClassCleanup()]

public static void AfterClass()

{

// ...

}

[TestMethod()]

public void BeforeClassCalled()

{

Assert.AreEqual(12, context);

}

}

The converter changes the member variables to be static and then modifies the signatures of both methods to conform to signatures required in Visual Studio 2005 Team System. The test succeeds after the conversion.

Ignore a Test

Both tools have the concept of ignoring a test. NUnit provides a field to describe why the test is being ignored; Visual Studio 2005 Team System does not.

NUnit Code

[TestFixture]

public class IgnoreMethodTests

{

[Test, Ignore("ignored test")]

public void IgnoredTest()

{

throw new Exception();

}

}

Visual Studio 2005 Team System Code (converterd)

[TestClass()]

public class IgnoreMethodTests

{

[TestMethod(), TestProperty("Reason", "ignored test"),
Ignore()]

public void IgnoredTest()

{

throw new Exception();

}

}

As you can see, the converter preserves the reason text by setting the “Reason” TestProperty. However, when the test is run this will not be present in the output.

Ignore a TestFixture

Both tools have the concept of ignoring all the tests in a test fixture. Similar to ignoring a test method NUnit provides a field to describe why the TestFixture is being ignored; Visual Studio 2005 Team System does not support a reason field.

NUnit Code

[TestFixture, Ignore("Testing Conversion")]

public class IgnoreTestFixtureTests

{

[Test]

public void TestInsideIgnoredTestFixture()

{

throw new Exception();

}

}

Visual Studio 2005 Team System Code (converterd)

[TestClass(), Ignore()]

public class IgnoreTestFixtureTests

{

[TestMethod()]

public void TestInsideIgnoredTestFixture()

{

throw new Exception();

}

}

In this case, the converter can not preserve the reason text because there is no way to set a TestProperty at the class level.

Assert.Equals/Assert.ReferenceEquals

When we were writing NUnit people would often get confused about using the Equals method on the Assert class. Less likely was the use of ReferenceEquals. However, it did happen. In order to make sure there was no confusion we overrode Equals and ReferenceEquals to throw AssertionException. The following tests depict this behavior.

Visual Studio Team System does not mimic this behavior, so any tests that are dependent on it will fail as the following example illustrates.

NUnit Code

[Test]

[ExpectedException(typeof(AssertionException))]

public void EqualsThrowsException()

{

object o = new object();

Assert.Equals(o, o);

}

[Test]

[ExpectedException(typeof(AssertionException))]

public void ReferenceEqualsThrowsException()

{

object o = new object();

Assert.ReferenceEquals(o, o);

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod(),
ExpectedException(typeof(AssertFailedException))]

public void EqualsThrowsException()

{

object o = new object();

Assert.Equals(o, o);

}

[TestMethod(),
ExpectedException(typeof(AssertFailedException))]

public void ReferenceEqualsThrowsException()

{

object o = new object();

Assert.ReferenceEquals(o, o);

}

When you run the converted tests you get the following test failures:

Test method Microsoft.Practices.ConversionTest.Samples.AreEqualTests.EqualsThrowsException did not throw expected exception.
Test method Microsoft.Practices.ConversionTest.Samples.AreEqualTests.ReferenceEqualsThrowsException did not throw expected exception.

ExpectedException

There are a number of differences with regard to how ExpectedException works between the tools. The first and most obvious is that in NUnit you can verify that the message in the thrown exception is what you are expecting. Since this is not a supported scenario is Visual Studio 2005 Team System the resulting code is very different than a simple translation.

Note: Not every ExpectedException attribute is converted like the following. If you do not look for the message the code will look identical between the two tools.

NUnit Code

[Test, ExpectedException(
typeof(InvalidOperationException), "message")]

public void ExceptionWithMessage()

{

throw new InvalidOperationException("message");

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod()]

public void ExceptionWithMessage()

{

try

{

throw new
InvalidOperationException("message");

Assert.Fail(…);

}

catch (InvalidOperationException exception)

{

Assert.AreEqual("message", exception.Message);

}

}

The next difference to consider is that Visual Studio 2005 Team System will not allow you to expect the class System.Exception. For example,

NUnit Code

[Test]

[ExpectedException(typeof(Exception))]

public void ExpectException()

{

throw new Exception();

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod(), ExpectedException(typeof(Exception))]

public void ExpectException()

{

throw new Exception();

}

The test compiles and runs successfully in NUnit. However when I run the converted code in Visual Studio 2005 Team System I get the following result:

UTA017: Microsoft.Practices.ConversionTest.Samples.ExpectedExceptionTests.ExpectException has invalid ExpectedException attribute. The type must inherit from Exception.

The last difference to point out with regard to ExpectedException is a capability that Visual Studio 2005 Team System has that is not present in NUnit. The Visual Studio 2005 Team System will allow you to expect exceptions that are contained as inner exceptions. Here is the example,

NUnit Code

[Test]

[ExpectedException(typeof(InvalidOperationException))]

public void FindingInnerException()

{

Exception innerException =

new InvalidOperationException("message");

throw new
TargetInvocationException(innerException);

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod(),
ExpectedException(typeof(InvalidOperationException))]

public void FindingInnerException()

{

Exception innerException =

new InvalidOperationException("message");

throw new
TargetInvocationException(innerException);

}

When I run this test in NUnit I get the following failure:

Microsoft.Practices.ConversionTest.Samples.ExpectedExceptionTests.FindingInnerException : Expected: InvalidOperationException but was TargetInvocationException

When the converted test is run in Visual Studio 2005 Team System it passes. I point this out because if you are used to the way that NUnit expects exception you might be surprised to have the code behave in a different fashion in Visual Studio.

Abstract Test Case

There are a number of times when it makes sense to move test methods to an abstract base class. The example that comes to mind is that you are writing tests for an interface. The tests in the base class describe the common behavior for all of the class that implements an interface. The tests in the derived classes only test behavior that is specific to that instance. Let’s begin by looking at an example in NUnit:

NUnit Code

public abstract class BaseFixtureWithSharedTests

{

protected int baseValue;

[SetUp]

protected virtual void BeforeTest()

{

baseValue = 12;

}

[Test]

public void TestInBaseClass()

{

Assert.AreEqual(12, baseValue);

}

}

[TestFixture]

public class InheritedTestFixture :
BaseFixtureWithSharedTests

{

[Test]

public void DerivedTest()

{

Assert.AreEqual(12, baseValue);

}

}

[TestFixture]

public class InheritedTestFixture2 :
BaseFixtureWithSharedTests

{

[Test]

public void DerivedTest()

{

Assert.AreEqual(12, baseValue);

}

}

When I run these tests in NUnit I get the following results:

· InheritedTestFixture

o DerivedTest

o TestInBaseClass

· InheritedTestFixture2

o DerivedTest

o TestInBaseClass

In short I get 4 tests because the [TestMethod] TestInBaseClass is considered part of the derived class. When I run the converter on the code I get the following:

Visual Studio 2005 Team System Code (converterd)

public abstract class
BaseFixtureWithSharedTestsDerivedAttribute

{

protected static int baseValue;

[TestInitialize()]

public virtual void BeforeTest()

{

baseValue = 12;

}

[TestMethod()]

public void TestInBaseClass()

{

Assert.AreEqual(12, baseValue);

}

}

[TestClass()]

public class InheritedTestFixtureDerivedAttribute :
BaseFixtureWithSharedTestsDerivedAttribute

{

[TestMethod()]

public void DerivedTest()

{

Assert.AreEqual(12, baseValue);

}

}

[TestClass()]

public class InheritedTestFixture2DerivedAttribute :
BaseFixtureWithSharedTestsDerivedAttribute

{

[TestMethod()]

public void DerivedTest()

{

Assert.AreEqual(12, baseValue);

}

}

The conversion yields 3 tests instead of 4. When I run the tests the two test methods defind in the derived classes run and succeed. The test in the base class yields the following not-runnable message:

UTA003: TestClass attribute defined on abstract class Microsoft.Practices.ConversionTest.Samples.BaseFixtureWithSharedTestsDerivedAttribute

The upside shown in this example is that you can move common initialization methods into base classes. The only caveat is that the TestClass attribute must be on the furthest most derived class for this to work. The downside is that you cannot move test methods into abstract classes. Here is an example that just demonstrates that common initialization can be moved into a base class:

NUnit Code

public abstract class BaseSetUpFixture

{

protected int value1;

protected int value2;

[SetUp]

public void BeforeTest()

{

value1 = 12;

value2 = 30;

}

}

[TestFixture]

public class DerivedBaseSetUpFixture : BaseSetUpFixture

{

[Test]

public void ComputeTest()

{

Assert.AreEqual(42, value1 + value2);

}

}

Visual Studio 2005 Team System Code (converterd)

public abstract class BaseSetupFixtureDerivedAttribute

{

protected static int value1;

protected static int value2;

[TestInitialize()]

public void BeforeTest()

{

value1 = 12;

value2 = 30;

}

}

[TestClass()]

public class DerivedBaseSetupFixtureNoAttribute :
BaseSetupFixtureDerivedAttribute

{

[TestMethod()]

public void ComputeTest()

{

Assert.AreEqual(42, value1 + value2);

}

}

In this case the test runs successfully. We can conclude that Visual Studio 2005 Team System does not support the abstract test case pattern. The converter does a best effort job at converting the code but complete conversion is beyond the scope of the automated converter. If it did try and convert the code completely it would likely yield code that would be undesirable and almost certainly less recognizable to the programmer. Even though VSTS does not support test methods in abstract base classes it does allow for common initialization and cleanup methods to be contained in base classes. The only thing you may have to do to your code to enable this is to move the TestFixture attribute from the base class to the furthest most derived classes which has no effect on the NUnit code.

Category Attribute on a Test
The Category attribute which was added in NUnit 2.2 is not supported in Visual Studio 2005 Team System. Once again, I did not want lose information in the conversion so I decided to make the category a TestProperty on the converted test method. What is lost in the conversion is the ability to run tests based on a category. A future enhancement might be to create a test list associated with the category. The issue with doing this at the moment is that in the developer suite there is no mechanism to run or create test lists. This functionality is only present in the Test Suite of Visual Studio 2005 Team System. Here is an example.

NUnit Code

[TestFixture]

public class CategoryTests

{

[Test, Category("sample")]

public void NormalAssert()

{

Assert.AreEqual(2, 2);

}

}

Visual Studio 2005 Team System Code (converterd)

[TestClass()]

public class CategoryTests

{

[TestMethod(), TestProperty("Category", "sample")]

public void NormalAssert()

{

Assert.AreEqual(2, 2);

}

}

The test runs as expected in both tools. However, you do lose the ability to run tests by Category by using Visual Studio 2005 Team System when using the converted code.

Category Attribute on a Class

NUnit 2.2 also allows you to put a Category attribute on a TestFixture. There is no corollary in Visual Studio 2005 Team System. In fact this conversion is even more invasive because there is no equivalent of TestProperty at the class level. Here is the example:

NUnit Code

[TestFixture, Category("sample")]

public class CategoryTestFixtureTests

{

[Test]

public void NormalAssert()

{

Assert.AreEqual(2, 2);

}

}

Visual Studio 2005 Team System Code (converterd)

// Category: "sample"

[TestClass()]

public class CategoryTestFixtureTests

{

[TestMethod()]

public void NormalAssert()

{

Assert.AreEqual(2, 2);

}

}

Because of my desire to make sure that information is not being lost in conversion I decided to just write the Category as a comment. This is obviously not ideal but if there is a better solution I am open to changing the converter.

Assert.Ignore

This was also a feature added to NUnit 2.2. This would allow you to ignore a test based on run-time information as opposed to compile-time information. This feature is not supported in Visual Studio 2005 Team System directly. Here is an example.

NUnit Code

[Test]

public void AssertIgnore()

{

Assert.Ignore();

}

[Test]

public void AssertIgnoreMessage()

{

Assert.Ignore("message");

}

Visual Studio 2005 Team System Code (converterd)

[TestMethod()]

public void AssertIgnore()

{

Assert.Inconclusive();

}

[TestMethod()]

public void AssertIgnoreMessage()

{

Assert.Inconclusive("message");

}

The conversion process converts the Assert.Ignore to be Assert.Inconclusive which is not exactly ignoring the test but it does cause the test to provide a different result.