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.
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.
How to get NUnit3TestAdapter pre-release packages
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)
For Nuget (PackageReference in csproj)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" />Tip 1: The PackageReference version require you to have the feed URL in the nuget.config file.
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.