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.

When your TFS/VSTS CI build is also used for a pull request, you often want to enable more checks before you let this go into the master (or any target) branch, and fail the build if these raise warnings.

It can be extra tests you want to run, code quality checks,  process checks, and  you might want to block the pull request if you have warnings from these.

Setting a single test task to fail could be done, but that only works well if you have a single step, with multiple tasks you will have build stops for one and every step, so it also reduces the error reporting granularity.  And, it is nice to be able to see what is an absolutely blocker, red, and what is quality issues, yellow.

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.

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.

When you do test runs with the Test Explorer in Visual Studio, you can select to use either a x86 or a x64 test runner.  Now, if you select to create an AnyCPU target for that component, it will not matter which one you choose, but if you select a target x86 or x64, the selected test runner has to match the selected target.  Otherwise no tests will be visible in the Test Explorer. 

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.

Download:  VS2012 Runsettingstemplate   VS2013 Runsettingstemplate

The VS2012/13 unit test feature can generate code coverage results.  It can do so for (nearly) any type of adapter you choose to use, MSTest, CPPTest (managed/native), XUnit and NUnit (but not Chutzpah (note 1)).

Assume you have a project with a set of unit tests included.  For this demonstration I have used multiple different test frameworks just to show that this applies to any of these frameworks.

You choose to analyze for code coverage:

The last year I have written three blog posts for the Microsoft MSDN ALM blog on unit testing. The posts focused on the new test explorer with its abilities to run tests in multiple frameworks, and utilizing traits to filter what to run, both in Visual Studio and on TFS Build.  I covered the adapters for NUnit, XUnit and Chutzpah.

How to manage unit tests in Visual Studio 2012 Update 1 : Part 1–Using Traits in the Unit Test Explorer