How to convert NUnit Assert.AreEqual to fluent Assert.That syntax easily

Once upon a time it was declared that an Assert statement should have constraints given as AreEqual and AreNotEqual. Further it was declared that it should be written in the opposite way of how a developer will think, that is with the expected value first and the actual value last. Why this was made so, is still unclear.

And then we end up with tons of code like:

Assert.AreEqual("Zulu", zulu.Name);
Assert.AreEqual("Z - Zulu", zulu.Description);
Assert.AreEqual(FlagType.Signal, zulu.Sort);
Assert.AreEqual(0.7, zulu.AspectRatio);

And it is not uncommon to see the two parameters swapped, making the displayed results harder to interpret.

If we write this with the fluent syntax:

Assert.That(zulu.Name,Is.EqualTo("Zulu");

This is the new fluent notation in NUnit (new and new…. it has been around for a very long time now, at least since NUnit 2.4, and that is pretty far back in time).

But – converting from one to another is not fun. Doing this manually is a very boring task.

Enter the NUnit.Analyzers, a new set of Roslyn based analyzers with refactoring. The project is still in preview, but is still very useful.
You add it to your solution as a nuget package, like any Roslyn analyzer, but instead of grabbing it off NuGet, you get it from the NUnit preview feed at MyGet.

When it is installed, it will display green squiggles for the lines above, making it look like:

Going to Show Potential fixes, or just pressing the light bulb.

As for any Roslyn warning, it shows you the potential change, and offers you also to fix these for the whole document, the whole project or even the whole solution.
We’re in for saving work here, so go all in!
The result will then be:

Which is much more readable test code!

Currently there are only a few warnings and refactorings present, but enough to already be very valuable. And, the team is hard at work to add more !

About terje

See http://about.me/terjes