NUnit has a very rich and readable constraint set. Normally you don’t need to do anything. But, there are some cases where it would be nice to be able to tweak these constraints. You can always wrap them and extend them that way, but then you lose all the other good stuff, like chaining. What is not so well known is that you can extend the existing constraints, they are **designed** to be extendable! In this post I will show how you can do that 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 unknown.

But 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.