Using xUnit with ASP.NET Core

Writing tests for ASP.NET Core applications can be done using xUnit. xUnit works on both.NET Framework and .NET Core. This post shows how to set up and use xUnit with ASP.NET Core applications in Visual Studio and on command-line. Targeting multiple frameworks is also covered.

Adding xUnit to solution

For automated testing we need a project with reference to our favorite testing framework. For this post it’s xUnit. We have default ASP.NET Core project and one additional project for tests like shown on screenshot on right.

We want to run xUnit tests from command line using dotnet utility and we would also like to use Visual Studio Test Explorer for running tests in dev boxes. For this we have to add the following package references to project.json file of tests project:

• xunit
• xunit.runner.dnx
• dotnet-test-xunit

In the beginning of project.json file we also have to specify the test runner to use. For this there’s testRunner attribute. Here’s my current project.json.

In dependencies section there is also reference to web application projectection. More about project.json can be found from project.json reference.

Writing simple tests

Now let’s write some simple dummy tests. I don’t focus here on what to test and how to do it in real scenarios. Here I just want to show how things work. So, here is my simple and primitive test class.

The first test checks if Index() method of home controller returns view with empty name or with name “Index”. Second test just fails immediately with exception.

Running tests in Visual Studio

To run tests in Visual Studio we select Tests from top menu and then Run and All Tests like shown on image below.

Visual Studio opens test explorer window and displays test results there. Test Explorer groups tests under failed and passed tests. If more information is needed about failed test then it’s possible to click on failed test to see exception or failed assertion and stack trace.

Note how Test Explorer is using nice names for tests. In code above we used DisplayName parameter with Fact attribute and this is where nice names of tests are taken.

Running xUnit tests on command-line

When building application on build server or some CI server or – why not – in Linux we want to run tests on command-line. For this we can use dotnet utility. To run tests on command-line we open console and move to tests project folder. There we run the following command:

dotnet test

It produces console output like this:

It’s perhaps good enough if we run tests manually and read the results but it’s not enough if we want to get out something that is okay for reporting. This is specially the case with CI servers with web interface. We are lucky because xUnit supports also XML-output. All we need is the following command:

dotnet test –xml results.xml

As a result we get same console output but results are also written to results.xml file. Here’s the content of this file in our case.

This XML is simple enough to generate HTML output of it.

Running xUnit tests for multiple runtimes

Now let’s see what happens if our web application targets multiple .NET Framework versions. Suppose we want application to run on .NET Core and .NET Framework 4.6. We have to add .NET Framework 4.6 to supported list of frameworks (in web application and test project). Here’s our new project.json for tests project.

Let’s run dotnet test again and see the console output.

NB! When writing this post the XML-output of xUnit doesn’t reflect results for all tested frameworks. It seems like only the first one gets to XML-file.

Wrapping up

xUnit is matured testing framework that works also with ASP.NET Core and .NET Core. Although all work is not finished yet it seems most important parts of xUnit already work well with ASP.NET Core. It’s possible to run tests in Visual Studio Test Explorer and on command-line. For applications targeting multiple frameworks tests are run for every supported framework. Although XML-output doesn’t reflect it yet it works fine with console output. xUnit doesn’t come with any complex requirements and it is possible to run it also on build and CI servers.