Last week I migrated several projects from NUnit to MSTest. The developers use the Developer version of Microsoft Visual Studio Team System, so they have integrated unit-test support for MSTest. In this post I show you all the problems and work I had to migrate the tests from NUnit to MSTest.

Less assert-methods in MSTest
In NUnit you have comparison assert methods, exception asserts, more type asserts, more utility asserts and so on (you see what I mean). There already exist little projects to add more assert methods for MSTest.
The problem with less assert method is the following:

Assert.Greater(nCount, 5);

This snippet is much more readable and maintainable than the following:

Assert.IsTrue(nCount > 5);

But that’s just my opinion. There are for sure people who like the second snippet more than the first one.

Attribute mappings
When you planning to migrate your NUnit Tests to MSTest you will need a mapping between the attributes of NUnit and MSTest. You’ll find on the internet mostly the following configuration:
[TestFixture] -> [TestClass]
[Test] -> [TestMethod]
[SetUp] -> [TestInitialize]
[TearDown] -> [TestCleanup]
[TestFixtureSetUp] -> [ClassInitialize]
[TestFixtureTearDown] -> [ClassCleanup]
That’s fine, but wait a minute! For two of those mappings you couldn’t just use find and replace. TestFixtureSetUp and TestFixtureTearDown aren’t static methods in NUnit. Methods with the attribute ClassInitialize or ClassCleanup has to be static. The method with the attribute ClassInitialize has even a parameter Testcontext. For those two methods you have to do a little bit more work.

TestFixtureSetup vs. ClassInitialize
As I mention above the difference between the attributes TestFixtureSetup and ClassInitialize (or TestFixtureTearDown and ClassCleanup), there’s still the question which one is conceptionally correct. Or why Microsoft did it different in comparison to NUnit.
I found the interesting answer in the book xUnit Test Patterns of Gerard Meszaros (on p. 384). Microsoft implements the JUnit approach, what means there will be for each test method a new instance of the test class. James Newkirk (one of the authors of NUnit) regret the decision in NUnit to us the same instance for all the test methods.

Ignore-attribute, no comment
The developers used a lot the attribute ignore in NUnit to deactivate unit tests for explorating testing. In NUnit you could add a comment to justify why the test should be ignored.
In MSTest the ignore attribute does also exists, but you couldn’t add a comment.

Resharper & MSTest
Since Resharper 4.5 you could also use this amazing tool with MSTest. Before the version 4.5 it was also possible to use it with MSTest, but you have to install a plug-in to do that.
From my perspective the Resharper unit test runner is much more better than the Visual Studio test runner.

ExpectedException and Visual Studio
In Visual Studio Professional and above you have an integrated unit-test runner (similar to eclipse, netbeans, etc.). There were a lot of unit-tests which expected an exception with the type Exception. That’s works fine in Resharper, on the build server (TFS) but not in the test runner of Visual Studio. Here you’ll receive the following warning:
UTA017: MyUnitTest has invalid ExpectedException attribute. The type must inherit from Exception.
This is a bug of the test runner, as others already described.

Execute several assemblies
One of the projects which I migrated from NUnit to MSTest runs unit tests of different assembles. So it had a nunit-file like that:
[code language=”xml”]
<NUnitProject>
<Settings activeconfig="Web">
<Config name="Web" appbase="Web" configfile="web.config" binpathtype="Auto">
<assembly path="bin\Product.NUnit.ComponentA.dll"/>
<assembly path="bin\Product.NUnit.ComponentB.dll"/>
<assembly path="bin\Product.NUnit.ComponentC.dll"/>
</Config>
</NUnitProject>
[/code]
I didn’t found a way to do that in MSTest.

Conclusion
With the migration the developers gain code coverage and the integration of unit-testing in Visual Studio (for those who hadn’t Resharper). On the other hand they lost readability, because they have to express an assertion with code with a primitive assert method.
If I could give you an advice, it’s the following: Migrate, if you have at least one of the Visual Studio Team System Editions (Developer, Test or Suite). With Visual Studio Professional (integrates a unit-test runner) and without Resharper, it is also an option to migrate to MSTest.