Changing unit-test frameworks with the help of fluent assertions

There are numerous reasons to why I keep using the little micro framework called Fluent Assertions. However recently I ran into a little situation that might not be so well documented so I thought I’d tell you about it here instead.



In a project I was involved in recently we had been using as our unit-testing framework for quite a while. However, a team decision was made to switch unit-testing frameworks and start using NUnit instead.

My idea with this blog post is to explain how we avoided some really nasty pitfalls in such a situation. Please also not that we could have switched from/to any popular unit-testing framework like MBUnit, MSpec, or MSTest (Fluent Assertions will support any of them).
First I’m going to show you a situation where you might have issues/problems when switching unit-testing frameworks and later how we actually managed to overcome them.

XUnit example

A very simple test in XUnit could look like this:


note: Pay special attention to the assert statement!

Switch to NUnit

Let’s now switch to NUnit and see what it takes:

  1. Firstly, we have to add a [TestFixture] attribute to every class that has test.
  2. Secondly, rename every [Fact] attribute to [Test] instead.
  3. Thirdly, the assert statement has to be changed since Assert.Equal is XUnit specific and is called Assert.AreEqual in NUnit which this screenshot will reveal (no-compile):

Now 1 & 2 could be accomplished with quite simple find&replace (or ReSharper) quirks. However 3 will require a lot more plus changing the code. Imagine I had a lot of tests…this would take quite some effort.



Now, let’s try the same thing but this time we’ll actually do it the same manner as we did in the project I talked about…with the help of Fluent Assertions.

Fluent Assertions

So, we had actually from the beginning been using Fluent Assertions.


One reason for using Fluent Assertions was for us that it enabled us to use a BDD-style of Given-When-Then (however not in those exact words) keywords when writing our tests. That was the only reason really.

XUnit example

Now, let’s see the same test as before but now I’ve written it Fluent Assertions style instead:


Switch to NUnit


That’s the same test after I switched to using NUnit. I still had to change the [Fact] attribute to [Test] which was quite easy. And I still had to add [TestFixture] to every test class.
BUT…I didn’t have to re-write a single test to have it compile…yay!!


, , ,

  1. #1 by Adam Ralph on April 4, 2013 - 15:33

    Out of interest, why did you switch from to NUnit. Most people switch the other way. is a ‘lessons learned from NUnit’ project.

    • #2 by Johan Leino on April 5, 2013 - 12:10

      not my decision really but I think it had to do with there not being any built-in support for XUnit in TeamCity and ReSharper. We did decide to go with XUnit from the beginning though…(over NUnit and MSTest if I remember correctly).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: