I recently had a discussion with some other developers about NUnit and MSTest. My personal preference is based on familiarity — originally from JUnit and TestNG, but also with NUnit. NUnit was around long before MSTest, and MSTest was not available with Visual Studio Express. I personally, haven’t used MSTest so I scoured the internet and picked some colleagues brains to come up with this post.
Here was my original question:
Thoughts on NUnit vs MSTest? I like NUnit because it’s more familiar coming from JUnit/TestNG and doesn’t depend on Visual Studio runtime, but it has it’s drawbacks. Any other opinions?
Here’s one exchange:
I like NUnit also even though my experience is with MSTest… VS2012 now supports Nunit also! We support both in the CD infrastructure. Most anything you can do in MSTest can be done with Nunit with a little understanding.
What is it about NUnit that you like even though you’re experienced with MSTest?
I have found NUnit to be supported and maintained as a first class solution for testing across most tools/test runners. Sonar and Go support NUnit natively. MSTest results are still not supported in Go and in Sonar it’s an add-on plugin.
MSTest is only good if you are 100% in MS technologies for build and deployment using TFS build agents. In our mixed technology environment NUnit bridges them all smoother than MSTest.
While we support both in GO, MStest requires Visual Studio to be installed on the agent (ridiculous, imo).
NUnit usually runs faster (due to reduced I/O, since it doesn’t produce a separate folder for each test run with shadow-copied assemblies).
The testing community in general prefers NUnit, so it’s easier to find help/examples.
I could go on, but here’s a couple of great articles:
Here are additional comments based on internet comments:
I agree that it’s ridiculous to require Visual Studio for test execution but I understand you can get around it with just the Windows SDK and some environment tweaks.
I wasn’t aware before of all the file pollution MSTest does, both with the references and VSMDI files and all the temp files it generates. With the Go agents we have set up neither of those are too big of issues anymore.
The syntax was my main preference, but I found you can use NUnit Assertions with MSTest — including Assert.That() and Assert.Throws() by doing this:
using Microsoft.VisualStudio.TestTools.UnitTesting; using Assert = NUnit.Framework.Assert;
But you can also use the independent Fluent Assertions which I think is even nicer. I still prefer the NUnit attribute names though.
Here is a somewhat dated comparison of the NUnit, MSTest attribute syntax
XUnit / Gallio has some nice data driven features (http://blog.benhall.me.uk/2008/01/introduction-to-xunitnet-extensions.html) but some weird syntax such as [Fact] instead of [Test] (http://xunit.codeplex.com/wikipage?title=Comparisons) and I think data providers should be a separate implementation than tests – like NUnit’s [TestCase TestCaseSource(methodName) http://nunit.org/index.php?p=testCaseSource&r=2.5
One last thing I like about NUnit is that it’s standalone. You could choose to include a specific version of the NUnit libraries with each project – and even fork if you want to add features because it’s open source, though that’s not really practical. But the open source nature – and that it’s older – means that you can find lots of information on the intertubes.
I wasn’t too impressed with a the Native NUnit runner inside Visual Studio 2012, but Resharper makes it nice. Some people on my team have complained about the extra weight Resharper adds, though I haven’t seen a problem (with 8GB RAM.) One complaint I can understand is the shortcut collisions R# introduces especially if your fingers were trained on Visual Studio, but for someone like me coming from Java IDEs the Resharper shortcuts are wonderful.
R# is a beautiful, beautiful thing – the extra weight is well worth it, what more could you ask for than IntelliJ in VS?
I can’t say I have much of a syntactical preference either way, but I would just say ‘Amen’ to earlier thoughts.