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.

 

Problem/Background

In a project I was involved in recently we had been using XUnit.net 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:

image

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):
    image

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.

 

Solution

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.

image

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:

image

Switch to NUnit

image

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 xUnit.net to NUnit. Most people switch the other way. xUnit.net 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:

WordPress.com Logo

You are commenting using your WordPress.com 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: