Migrating nUnit test to Microsoft Test

The other day I was “blessed with” the opportunity of porting a nUnit based test project to Microsoft Test.  Why would anyone do that?
Well, in my case it was the easiest as the test project was involved in Microsoft TFS CI build process that was using Microsoft Test.

So how do you actually do that?

Step 1:  Make Visual Studio recognize the project as being a test project – instead of just a “normal” class library.  you can see if your project is a test project when you try to add items to the project.  In a Microsoft test project, you can when right-clicking the project in the solution explorer and choosing “Add” see the menu item “New Test…”.   However in a normal class library you will not see this item – hence the classlibrary is not a Microsoft Test project.

I had to do a little bit of hacking here, manually editing the project file in a text-editor (e.g. Notepad++).

Here I inserted the line:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

As shown in my project file here:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>9.0.30729</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{21EF515E-25F4-4C90-8470-2085E8C56FE7}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>TriGemini.UnitTest.Common</RootNamespace>
    <AssemblyName>TriGemini.UnitTest.Common</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
    <SccProjectName>SAK</SccProjectName>
    <SccLocalPath>SAK</SccLocalPath>
    <SccAuxPath>SAK</SccAuxPath>
    <SccProvider>SAK</SccProvider>
    <FileUpgradeFlags>
    </FileUpgradeFlags>
    <OldToolsVersion>3.5</OldToolsVersion>
    <UpgradeBackupLocation />
    <IsWebBootstrapper>false</IsWebBootstrapper>
    <TargetFrameworkProfile />
    <PublishUrl>publish\</PublishUrl>

Now reloading the project and the project was now recognized as a Microsoft Test project.

Step 2: Add a reference to the Microsoft.VisualStudio.TestTools.UnitTesting assembly.

Step 3: Remove all references to nUnit assemblies

using Resharper made it quite simple to spot the errors/indifferences and correct them.   Microsoft Test uses a slightly different “test-dialect” (attributes/asserts).
Making it necessary to:

Replace all [TestFixture] attributes with the [TestClass] attribute and on each test method replacing the [Test] attribute with the [TestMethod] attribute.
Further more I had to change some of my negative tests, where I was using the [ExpectedException] attribute that in nUnit gives the opportunity of testing the actual exception message – which isn’t possible in the Microsoft Test dialect.

Other minor changes I had to do was e.g. to change:

Assert.IsNotNullOrEmpty(xxx);

to the less-readable (but Microsoft Test compatible) construct:

Assert.IsFalse(String.IsNullOrEmpty(xxx));

… and that was basically it – I’d converted my nUnit project to a Microsoft Test project.  Here’s a little quick-reference of the differences between the nUnit and Microsoft attributes:

If you have to choose between nUnit and Microsoft Test, I personally am in favor of nUnit.  nUnit provides more logical naming (but I guess that’s just a habbit) but also better and shorter constructions for tests.   In my case there was however no choice in doing the conversion to Microsoft Test.