NUnit vs. MbUnit vs. MSTest vs. xUnit.net?

NUnit is probably the most supported by the 3rd party tools. It's also been around longer than the other three I personally don't care much about unit test frameworks, mocking libraries are IMHO much more important (and lock you in much more). Just pick one and stick with it.

NUnit is probably the most supported by the 3rd party tools. It's also been around longer than the other three. I personally don't care much about unit test frameworks, mocking libraries are IMHO much more important (and lock you in much more).

Just pick one and stick with it.

– dplante Jun 5 '09 at 20:32 9 I like Moq, RhinoMocks is also good. – Alexander Kojevnikov Jun 8 '09 at 7:27 3 It might also be worthwhile to check Pex and Moles, the moles part especially is useful for mocking. – Charles Prakash Dasari Oct 23 '10 at 23:59 and I believe it's also the leanest & fastest.

– ssg Jun 14 at 8:06.

I know this is an old thread, but I thought I'd post a vote for xUnit.NET. While most of the other testing frameworks mentioned are all pretty much the same, xUnit. NET has taken a pretty unique, modern, and flexible approach to unit testing.It changes terminology, so you no longer do you define TestFixtures and Tests...you specify Facts and Theories about your code, which integrates better with the concept of what a test is from a TDD/BDD perspective.

XUnit. NET is also EXTREMELY extensible. Its FactAttribute and TraitAttribute attribute classes are not sealed, and provide overridable base methods that give you a lot of control over how the methods those attributes decorate should be executed.

While xUnit. NET in its default form allows you to write test classes that are similar to NUnit test fixtures with their test methods, you are not confined to this form of unit testing at all. You are free to extend the framework to support BDD-style Concern/Context/Observation specifications, as depicted here.

XUnit. NET also supports fit-style testing directly out of the box with its Theory attribute and corresponding data attributes. Fit input data may be loaded from excel, database, or even a custom data source such as a Word document (by extending the base data attribute.

) This allows you to capitalize on a single testing platform for both unit tests and integration tests, which can be huge in reducing product dependencies and required training. Other approaches to testing may also be implemented with xUnit.NET...the possibilities are pretty limitless. Combined with another very forward looking mocking framework, Moq, the two create a very flexible, extensible, and powerful platform for implementing automated testing.

6 While this was true a year+ ago, NUnit has since added most of the attributes in question. In NUnit you can write tests either way. – Mark Levison Nov 16 '10 at 16:21 2 Its not so much about which attributes are available, but how they can be used.XUnit.NET was designed from the ground up to be a highly flexible and extensible framework that did not lock you into any particular method of testing, and does not require you to regularly update the core framework to get the latest capabilities.

– jrista Nov 22 '10 at 4:57.

I wouldn't go with MSTest. Although it's probably the most future proof of the frameworks with Microsoft behind it's not the most flexible solution. It won't run stand alone without some hacks.So running it on a build server other than TFS without installing Visual Studio is hard.

The visual studio test-runner is actually slower than Testdriven. Net + any of the other frameworks. And because the releases of this framework are tied to releases of Visual Studio there are less updates and if you have to work with an older VS you're tied to an older MSTest.

I don't think it matters a lot which of the other frameworks you use. It's really easy to switch from one to another. I personally use XUnit.

Net or NUnit depending on the preference of my coworkers. NUnit is the most standard.XUnit.Net is the leanest framework.

7 I've been dragged kicking and screaming to this same conclusion. I really wanted to use MSTest because of it's integration with Visual Studio, but that's also its weakness. I need to run tests on a non-Microsoft build server and there aint no way I am installing Visual Studio on it just to get that.It's a shame that Microsoft produces great tools and then renders them almost unattainable.

– Tim Long Mar 10 '10 at 19:48.

I personally don't like xUnit. Net because its adoption of a confusing naming scheme such as "Fact", "Theory" etc, instead of the common jargon. There are numerous examples of such (the chart shows them).

Besides the confusion, it makes migration from one framework to another a Replace All hassle. I really wonder which fundamental problem they have addressed with those changes.

24 Based on the downvotes without comments, we can also add that xUnit. Net has built up a fanboy community who lack proper articulation and rebuttal skills. – ssg Mar 4 '10 at 8:02 10 I can assure you they're not testkiddies that want to dream up new names for stuff.

Have a play with it - I dismissed it for far too long and love it now. And go easy on the drivebyt -1ers! – Ruben Bartelink Apr 6 '10 at 7:43 5 Given xUnit.NET's flexibility, it is a trivial matter to extend the Fact attribute to create a Test attribute that functions the same way.

If your beef is with having to search-and-replace...your approaching the problem the wrong way. XUnit.NET solves a lot of problems, not simply because it is a different framework...but because it is an extensible framework that allows YOU to figure out how to provide solutions to testing problems. See my answer above for more.

– jrista Jun 22 '10 at 22:31 6 @jrista I'm not saying xUnit.NET isn't flexible. I'm saying that a test is not a fact but a piece of code. And a bunch of tests do not make a theory either.

This kind of naming is at least stupid, and has no justification. If someone went this far in absurdity, they might as well have done other smelly stuff. Besides the frustration it causes, I regard this as a bad sign.

That's all I'm saying. There is even a document titled "Running a theory" for God's sake. And you mention flexibility.

Here is my theory, run it now. – ssg Jun 23 '10 at 8:33 2 No, that's the excuse you'd hear from it's creator: " that's why". But if they really had their mind wrapped around BDD concept, we wouldn't see "Assert"s.

Instead we would see such an elegant, perfectly designed framework which would have "EnsuresThat", "RequiresThat", "ButNeverDoesThat" kind of constructs; something like code contracts. And I'm saying it, this is an half-assed solution to a problem that never existed (BDD'ers have no problem with NUnit/JUnit conventions). And this IS A BAD DESIGN which IS A BAD SIGN for the future of xUnit.NET.

– ssg Jun 25 '10 at 11:06.

Since we have some experience with both MBUnit v3.3 and NUnit 2.5. X now, I can compare both: Although semantics and syntax are very similar between both, NUnit's API design is less intuitive. You need to know when to use Assert. *, StringAssert.

*, CollectionAssert. * and sometimes string related functions in Assert. *.

The parameter order for "expected" and "value" are also confusing in NUnit. MBUnit follows common sense. For instance GreaterThan(value, expected) makes more sense yet NUnit uses convention expected, value which basically looks more like a LessThan.

We've found that it's easier to implement GUI tests on MBUnit because AssemblyFixture allows you to iterate all tests over different global parameters such as "web browser"s. In NUnit we had to have different config files for each browser which was a hassle to manage. MBUnit's GUI client Gallio Icarus is very bloated and very slow.

NUnit's GUI client on the other hand lacks many features (such as single click debugging). Test execution times of command-line clients are almost the same. ReSharper test runner is the best/fastest/easiest to use environment for both.

Yet we had duplicate test issues with generational NUnit tests in it's latest version 6.1. MBUnit supports parallelized tests. This comes in handy when you have isolated tests that need to Sleep for long periods. Meanwhile you can run other irrelevant tests in parallel, increasing execution time a lot.

There is a love and hate relationship between MBUnit and ReSharper. R# doesn't support MBUnit out of the box while MBUnit has been having hard time to keep compatibility for it's own R# plugin. We had seen many serious regressions in MBUnit releases yet NUnit always kept pretty much stable releases.

NUnit's generational test support, although improving fast, did not yet catch MBUnit's. You can't feed your tests from non-static members for instance which is possible in MBUnit. NUnit also does not support Pairwise joins for combinations.

MBUnit seems more forgiving when it comes to placement of attributes. You can put a Column attribute before function declaration and MBUnit assumes that it belongs to first parameter of the function. NUnit strictly requires you to put these at correct places.

That may not be good or bad necessarily but it's just something we discovered during our switch-tests. NUnit lacks StructuralEqualityComparer which saves you time to implement object comparers to get by-value comparison for asserts. There is no shorter way to do it in NUnit other than writing test-only comparers for your classes, which is harder.

NUnit does not have equivalent of Assert.ForAll. You have to do a foreach(...) Assert. Xxx instead.

For whatever it's worth MBUnit has support for running tests of other frameworks inside it's own runner. I never needed that and I don't know who would. Yet it's there.

In overall, I find MBUnit easier to use, more intuitive. I'm also happy that NUnit is quickly adopting proven successful ideas on different frameworks. I hope NUnit can catch up and we can benefit from competition.

Very interesting to hear about the experiences from someone who's used both frameworks! – Batibix Jan 6 at 1:01 1 +1 for the mention of MbUnit's StructuralEqualityComparer. I knew that it would be useful to someone one day or later :) – Yann Trevin Nov 4 at 7:29.

It's not a big deal on a small/personal scale, but it can become a bigger deal quickly on a larger scale. My employer is a large Microsoft shop, but won't/can't buy into Team System/TFS for a number of reasons. We currently use Subversion + Orcas + MBUnit + TestDriven.NET and it works well, but getting TD.

NET was a huge hassle. The version sensitivity of MBUnit + TestDriven.NET is also a big hassle, and having one additional commercial thing (TD. NET) for legal to review and procurement to handle and manage, isn't trivial.

My company, like a lot of companies, are fat and happy with a MSDN Subscription model, and it's just not used to handling one off procurements for hundreds of developers.In other words, the fully integrated MS offer, while definitely not always best-of-bread, is a significant value-add in my opinion. I think we'll stay with our current step because it works and we've already gotten over the hump organizationally, but I sure do wish MS had a compelling offering in this space so we could consolidate and simplify our dev stack a bit.

2 ReSharper does have a compelling offering in this space! – Squirrel Mar 6 '09 at 14:35.

It's not a big deal, it's pretty easy to switch between them. MSTest being integrated isn't a big deal either, just grab testdriven.net. Like the previous person said pick a mocking framework, my favourite at the moment is Moq.

Nunit doesn't work well with mixed-mode projects in C++ so I had to drop it.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.