How to run xunit test with vNext Build

I was recently asked for help getting xunit test to run using VSO build vNext. In this post I will walk you through how I was able to get everything working.

I created a simple Class Library project and added it to source control. Make sure and choose a Windows - Class Library and not a Web Class Library (Package).

Now using Nuget Package Manager add a reference to xunit and xunit.runner.visualstudio. To the class1.cs file add a using for Xunit and add a test method.

Run the test and makes sure it passes.

Now check in your changes so we can configure the build. Navigate to VSO and the Build Hub. Add a new build using the Visual Studio template.

Update the solution path on the Visual Studio Build step and update the Mappings on the Repository tab. Now return to the Build tab so we can correct the Visual Studio Test step to run our xunit test. The key to getting the xunit test to run is setting the Path to Custom Test Adapters value under the Advanced section. The value has to point to the folder under the Packages folder that contains the xunit test adapter. I used the following path:


Now simply save and queue your build.

Comments (8) -

  • Sam
    Nice and terse.
    Do you know how to achive the same result with on-prem TFS2012?

  • Hi Donovan, I'm trying to use this example for running xUnit tests on VSO but getting the error message ##[error]Could not find file 'C:\a\1\s\packages'.  

    Any ideas what I am missing?
    • Sorry for the delay.  Make sure you set the Path to Custom Test Adapters.
      • Having the same issue as Alan ,

        Have tried.


        Notta !  I've read your article along with 10 others that advise similar approaches.  Is there no way of determining where on Team Services hosted agent that the Nuget packages are being installed to ?  

        logs from the Nuget restore don't show much.  etc.

  • Donovan,

    I'm having a problem where I have a VS2013 solution I'm trying to build with VNext. It is a web project and the unit tests are in a separate project, which is proper design. During the build process, when it gets to the test project I get:

    2016-02-12T15:20:04.9595528Z      1>Project "C:\a\1\s\XXX\src\XX.XX.XX\XX.XX.XX.sln" (1) is building "C:\a\1\s\XXX\src\XX.XX.XX\XX.XX.XX.Services.OData\XX.XX.XX.Services.YY.csproj" (4:4) on node 1 (Publish target(s)).
    2016-02-12T15:20:04.9595528Z      4>_DeploymentUnpublishable:
    2016-02-12T15:20:04.9605536Z          Skipping unpublishable project.

    Then, when it reaches the test step I get:

    No test assemblies found matching the pattern: '**\*tests*.dll'
    • Does your test project have the word 'tests' anywhere in the name? If not it will not be found.  The test task searches for any dll that has the word tests in it.  You can change the pattern to fine your dll.
      • Donovan,

        The test assemblies were not part of the published project so they don't get pushed to the build server. If I add the test assembly in the References they get published/deployed as part of the build and then they get found and the xunit tests execute. However, this isn't desired. We certainly don't want the test assemblies getting published just so the unit tests can execute during the build process. Is there a workaround in vNext for this problem?
        • When I want to run unit test as part of my build my sln will have both the test projects and the projects to be tested in a single solution.  However, after the build I use the Copy and Publish Build Artifacts task to select just the files I want to publish. This will leave the test dlls behind on my build machine only selecting the files that need to be in my release.
          However, just because you publish files as artifacts does not mean they have to be deployed from the release. There are times I also want to run tests during my release like UI tests. For those tests to be executed during my release the dlls holding those tests must also be published from our build.  The release will deploy the actual application and only use the test dlls to run the UI tests from the agent after the real application has been deployed to the environment.

Add comment