Automated Deployment with .Net Core 2.0 Unit Tests

If you’re using an automated deployment system or continuous integration, you’ll need to get good at compiling and running your unit tests from the command line.  One of the issues I found with .Net Core was the difficulty in making xUnit work with Jenkins.  Jenkins has plug-ins for different types of unit testing modules and support for MSTest is easy to implement.  There is no plug-in that makes xUnit work in Jenkins for .Net Core 1.  There is a plug-in for nUnit that works with the xUnit output if you convert the xml tags to match what is expected by the plug-in.  That’s where this powershell script becomes necessary:

https://blog.dangl.me/archive/unit-testing-and-code-coverage-with-jenkins-and-net-core/

If you’re attempting to use .Net Core 1 projects, follow the instructions at the link to make it work properly.

For .Net Core 2.0, there is an easier solution.  There is a logger switch that allows you to output the correct xml formatted result file that can be used by the MSTest report runner in Jenkins.  You’ll need to be in the directory containing the project file for the unit tests you want to run, then execute the following:

dotnet test --logger "trx;LogFileName=mytests.trx"

Run this command for each unit test project you have in your solution and then use the MSTest runner:

This will pickup any trx files and display the familiar unit test line chart.

The dotnet-test command will run xUnit as well as MSTest so you can mix and match test projects in your solution.  Both will produce the same formatted xml output trx file for consumption by Jenkins.

One note about the powershell script provided Georg Dangl:

There are environment variables in the script that are only created when executed from Jenkins.  So you can’t test this script from outside of the Jenkins environment (unless you fake out all the variables before executing the script).  I would recommend modifying the script to convert all the $ENV variables into a parameter passed into the script.  From Jenkins the variable names would be the same as they are in the script (like $ENV:WORKSPACE), but you can pass in a workspace url to the script if you want to tests this script on your desktop.  Often times I’ll test my scripts on my desktop/laptop first to make sure the script works correctly.  Then I might test it on the Jenkins server under my user account.  After that I test from the Jenkins job itself.  Otherwise, it could take a lot of man-hours to fix a powershell script from re-running a Jenkins job just to test the script.

 

 

One thought on “Automated Deployment with .Net Core 2.0 Unit Tests

Leave a Reply