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.

Debugging the NUnit3TestAdapter Take 2

Background

In version 4.2 of the NUnit3TestAdapter debugging has been made a bit simpler. For the earlier versions, see Debugging the NUnit3TestAdapter.

Introduction

A test adapter sits between a TestHost and the test framework. If you use Visual Studio or dotnet, both starts up a TestHost as a separate process. The testhost is responsible for locating the adapters, and then invoke them to run the test frameworks on the test code. Debugging an adapter is hard, because it sits between these two processes, of which you have no control. The way to handle this is to enable launching the adapter in debug mode. This post details how you do that.

Debugging the NUnit3TestAdapter

Introduction

A test adapter sits between a TestHost and the test framework. If you use Visual Studio or dotnet, both starts up a TestHost as a seperate process. The testhost is responsible for locating the adapters, and then invoke them to run the test frameworks on the test code. Debugging the adapters is hard, because it sits between these processes, of which you have no control. The way to handle this is to enable launching the debugger from inside the adapter code. This post details how you do that.

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.

Adapter pre-releases

We publish pre-release packages for every pull request merge to the master branch in the NUnit3TestAdapter project.    They are published to our NUnit MyGet feed,

Feed:      https://www.myget.org/F/nunit/api/v3/index.json

Instructions for getting it for the different package tools, and also to see which is the latest version, go here:

https://www.myget.org/feed/nunit/package/nuget/NUnit3TestAdapter 

For NuGet (package.config)

Install-Package NUnit3TestAdapter -Version 3.10.0-dev-00702 -Source https://www.myget.org/F/nunit/api/v3/index.json

<PackageReference Include="NUnit3TestAdapter" Version="3.10.0-dev-00702" />