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.

NUnit as a project has a tradition of keeping backwards compatibility. It ensures that even if you stay on a earlier version of Visual Studio, .net FrameWork, or whatever it is, NUnit should continue to work even with upgrades of NUnit.
So also for the NUnitAdapter. It should work on any version of Visual Studio after the 2012 version. We have managed to maintain that. However, over time it has become harder and harder to verify the compatibility. Microsoft has increased their release pace, and the number of versions and variations of Visual Studio has subsequently increased tremendously over the last years. We have not found an easy way to test all the possible variations, so have had to do a set of minimum tests, then respond quickly when someone raises an issue. Fortunately, there have not been many of those. We rely to a large degree on peer reviews using pull requests, which have weeded out most of these issues.

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.

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);

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.

Test Adapters come in two flavors, VSIX based and Nuget based. The VSIX based are installed as extensions to Visual Studio and therefore will apply to all solutions you load, The Nuget based adapter packages must be installed at least into one project in your solution and will only work for that solution.

All versions of Visual Studio have supported both flavors, but from Visual Studio 2017 Update 15.8 (Preview 4) the VSIX based adapters for C# and Visual Basic will be deprecated.

I have had a need to have more easy access to information on how to do certain stuff, and have some easy access to simple code blocks, or templates, I can copy/paste.  A blog post is for me somewhat more extensive, and that format was not really suited for smaller notes.  So I decided to write them down as “recipes”, which is a small post, larger than a post-it, but smaller than a full blown blog post.

The Visual Studio Test Explorer can be a bit picky about showing tests.  There are multiple reasons for why they don’t always show up when you expect them to do, and most of the cases are PEBKAC type of issues.  That doesn’t mean it is easy, there are just becoming too many variations, and Visual Studio does not tell you what is really wrong.

The different variations of targets and adapters doesn’t make this easier.  To help in diagnosing this, I have created the diagnostic flow chart shown below.   Further below you will find the comments for each block and how to rectify the issues, if you don’t already know.  The flowchart is mostly general, although I use NUnit as the default adapter in the examples.

The Visual Studio Test Explorer user interface have been nearly the same since 2012, with only a few minor updates.  One thing that have annoyed a few people are how the test names are displayed.   The Test Explorer have got a bit of critique on this, but it is not that hardcoded.  It can be tweaked!   With NUnit3 and the NUnit3TestAdapter version 3.8 you can configure this naming yourself, which makes for some interesting possibilities.

Introduction

You have all seen it, you have all done it: Written code using the static methods from the System.IO namespace for handling directories and files.   Or, you are maintaining legacy code where that usage is common in certain places.  And now the code is huge,  you have no unit tests, because unit testing classes that directly access the file system is just pain,  and the cost of a rewrite is too big.

NUGET

The current version 1.2 of the NuGet adapters for NUnit works with the VS 2015 Preview (and earlier CTPs). 

You can find them here:  http://www.nuget.org/packages/NUnitTestAdapter/  and with framework: http://www.nuget.org/packages/NUnitTestAdapter.WithFramework/

Add one of these to your solution and it works without having the VSIX installed, both for VS2015 and for TFS build, including VSO build.  Note that you only need to add one of these to one of your projects in the solution. 

This issue is resolved in the latest ReSharper release, version 8.2.0.2160, download here. 

The issue appears when using the Test Explorer to run tests in any of the frameworks mentioned in the title.  The tests are shown in the Test Explorer, but are not executed.  It may look like this:

Note:  The tests shown dimmed are NUnit and XUnit tests, which have the issue. The other tests are MSTests, which are not affected. The tests are discovered by the adapter, but not executed.