Convert VSTest to MTP in Existing .NET Project

It appears that the time has come where we are forced to abandon VSTest and convert to using Microsoft Test Platform (MTP) in our testing applications.

I use Azure DevOps for deploying applications to VMs in Azure. I used YAML files to script out the process. I upgraded my test applications to xunit.v3 NuGet package without having to make any changes to my projects or Azure YAML scripts. However, when I upgraded to xUnit v3 to v4.0, that changed. VSTest is no longer supported with the existing syntax.

I received the following message when the Azure DevOps YAML executed:

##[warning]No test result files were found.
##[error]Dotnet command failed with non-zero exit code on the following projects : [ 'D:\a\1\s\API.Tests' ]

All of this is supported in .NET 10 and up, so not sure you can accomplish any of this in a lower runtime.

These are the steps that I had to take in order to get my Xunit test projects to run under Microsoft Test Platform (MTP).

Step 1

Edit your csproj file for the test application and change:

<OutputType>Library</OutputType>
to
<OutputType>Exe</OutputType>

Step 2

In the same section, add the following lines if they don’t already exist:

<UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner>
<EnableMSTestRunner>true</EnableMSTestRunner>
<EnableMicrosoftTestingExtensionsJUnitReport>true</EnableMicrosoftTestingExtensionsJUnitReport>

Step 3

In the section of your csproj file where dependencies are loaded, see if you have these line, with any versions and remove them. Note that you can do this in the Manage NuGet Packages for Solution option too.

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.9.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="3.1.5">

Step 4

Upgrade xunit to version 4.x. Note that you can do this in the Manage NuGet Packages for Solution option too.

<PackageReference Include="xunit.v3" Version="4.0.0" />

Step 5

See if a global.json file exists in the same folder as your solution (sln) file. If not create one. Make sure that it has to following entry:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Step 6

I have YML (yaml) files for the deployments as part of my projects that run when merged with particular branches. In order to run the new MTP section, I had to run it as a script:

- script: dotnet test {project folder}\{project name}.csproj --configuration $(buildConfiguration) --no-build --results-directory $(Build.ArtifactStagingDirectory)\TestResults --report-xunit-junit 
  displayName: "Run API Tests"

That should do it.

For reference, this is my old Azure DevOps YAML that stopped working after xunit.v3 v4 was installed:

- task: DotNetCoreCLI@2
  displayName: 'Run API Tests'
  inputs:
    command: 'test'
    arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura'
    publishTestResults: true
    projects: '{project name}' 

Testing Locally

Once you build, you can test locally by going to the test project bin\debug\net10.0 folder and look for the project.exe. Run that from the command line and you should see the new MTP output which has colors. The old VSTest did not have color output. I sure hope we’re not all having to do this so that we could have color in the output :-).

If you navigate to the same folder as you solution file, you can also execute the dotnet test:

dotnet test C:\{path to solution}\{project name}.csproj --configuration debug --no-build --results-directory C:\Temp\TestResults --report-xunit-junit

Language Folders

When changing the application type to an Exe, we will now get the default language folders in our bin folder after build. You may not be concerned about this, but you if you’d like, you can add this to the project file as well:

<SatelliteResourceLanguages>en-US</SatelliteResourceLanguages>

This will prevent all extraneous folders from being created during the build. This is the same setting used in UI and web-based projects.

References:

Here are the general instructions provided by Microsoft to convert to MTP:

https://learn.microsoft.com/en-us/dotnet/core/testing/migrating-vstest-microsoft-testing-platform

Author: Jack Yasgar

Jack Yasgar has been developing software for various industries for two decades. Currently, he utilizes C#, JQuery, JavaScript, SQL Server with stored procedures and/or Entity Framework to produce MVC responsive web sites that converse to a service layer utilizing RESTful API in Web API 2.0 or Microsoft WCF web services. The infrastructure can be internal, shared or reside in Azure. Jack has designed dozens of relational databases that use the proper primary keys and foreign keys to allow for data integrity moving forward. While working in a Scrum/Agile environment, he is a firm believer that quality software comes from quality planning. Without getting caught up in analysis paralysis, it is still possible to achieve a level of design that allows an agile team to move forward quickly while keeping re-work to a minimum. Jack believes, “The key to long term software success is adhering to the SOLID design principles. Software written quickly, using wizards and other methods can impress the business sponsor / product owner for a short period of time. Once the honeymoon is over, the product owner will stay enamored when the team can implement changes quickly and fix bugs in minutes, not hours or days.” Jack has become certified by the Object Management Group as OCUP II (OMG Certified UML Professional) in addition to his certification as a Microsoft Certified Professional. The use of the Unified Modeling Language (UML) provides a visual guide to Use Cases and Activities that can guide the product owner in designing software that meets the end user needs. The software development teams then use the same drawings to create their Unit Tests to make sure that the software meets all those needs. The QA testing team can use the UML drawings as a guide to produce test cases. Once the software is in production, the UML drawings become a reference for business users and support staff to know what decisions are happening behind the scenes to guide their support efforts.

Leave a Reply

Your email address will not be published. Required fields are marked *