Unit Tests not discovered in Visual Studio 2017

Question

I have been struggling with VS 2017 since I installed it. Now it seems Unit Tests will only run from the command line "dotnet test."

My project is .NET Core 1.1.1. I have the SDK and the framework update for 1.1.1 installed.

I have tried the sample at MSDN (https://msdn.microsoft.com/en-us/library/ms182532.aspx) which also fails exactly the same way.

All NuGet packages for the tests and the main project are current. And both the test project and the main project build without errors. An the tests run successfully from the command line.

Has anyone gotten Unit Tests to run in VS 2017, if so how?

Thanks, John

---

Update - Extend

Here is an example of a simple test project that is not working on GitHub. This is an example with xUnit but I have tried NUnit and visual studio built in MS tests. No matter what testing or what changes I make I cannot get the VS test runner to find any tests.

What I've Tried

• Deleting VS test cache files DEL %TEMP%\VisualStudioTestExplorerExtensions
• Restarting VS
• Closing/Opening test explorer
• for xUnit installed Microsoft.DotNet.InternalAbstractions (see SO post)
• for NUnit ensure adapter installed and same version (3) as NUnit package
• test -> test settings -> default processor architecture is set to x86

The Question
Can anyone please provide a working example of a .Net Core 1.1.0 solution in VS2017 (.csproj project files) where the VS test explorer successfully finds the unit tests OR show me the issue in the example given.

Answer 1

In my case, it turned out that I simply had to upgrade my test adapters and test framework. Done.

Example using the NuGet Package Manager:

Answer 2

This just worked for me (don't know if it is the result of changing workspaces that corrupted something):

Deleting VS test cache files in %TEMP%\VisualStudioTestExplorerExtensions and restart VS2017.

Answer 3

The API for test adapters for .NET Core changed with the release of Visual Studio 2017 and the move from the project.json format to the csproj format. This made the existing dotnet-test-* adapters like dotnet-test-nunit obsolete.

The adapters have been updated, but the way you set up and run tests in Visual Studio or on the command line with dotnet test requires different references in your test projects. Beware of any documentation you find that reference packages in the dotnet-test-* format because they are outdated.

First, your test project must target a specific platform, either .NET Core or .NET Framework. It cannot target .NET Standard even if the code you are testing is .NET Standard. This is because the target of the tests indicates which platform to run the tests under. .NET Standard is like a PCL (Portable Class Library) in that it can run on many platforms.

Next, you need to add references to Microsoft.NET.Test.Sdk, your test framework of choice and a compatible test adapter. For NUnit, your references will look like this,

<itemgroup>
    <packagereference Include="Microsoft.NET.Test.Sdk" Version="15.0.0"></packagereference>
    <packagereference Include="NUnit" Version="3.7.1"></packagereference>
    <packagereference Include="NUnit3TestAdapter" Version="3.8.0"></packagereference>
</itemgroup>

A comment above mentions adding,

<ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>

This isn't strictly required, but can help. It is added automatically to all unit test projects by Visual Studio to help it quickly find projects with tests.

If your tests don't appear in Visual Studio, the first thing to try is closing your solution and then re-opening them. There appear to be bugs in Visual Studio not detecting changes to projects when you edit them.

For more information, see Testing .NET Core with NUnit in Visual Studio 2017.

Answer 4

Forgetting to make the test class public prevents the test methods inside to be discovered.

I had a default xUnit project and deleted the sample UnitTest1.cs, replacing it with a controller test class, with a couple of tests, but none were found.

Long story short, after updating xUnit, Test.Sdk, xUnit.runner packages and rebuilding the project, I encountered a build error:

Error xUnit1000 Test classes must be public

Thankfully, the updated version threw this exception to spare me some trouble.

Modifying the test class to be public fixed my issue.

Answer 5

I had the same issue and got it to work by doing the following:

• First, close all open Visual Studio instances and delete this folder: %TEMP%\VisualStudioTestExplorerExtensions (Running tests with Visual Studio)
• Go to your NuGet package manager and install Microsoft.NET.Test.Sdk (15.3.0-preview-20170425-07) first and then install xunit.runner.visualstudio (2.3.0-beta1-build1309). See attached NuGet screenshot to see all the packages I had to install to get the latest VS 2017 to detect my tests.

Answer 6

In my case, I target the test project to x64 Architecture and the test setting Architecture (test > Default Processor Architecture) changed was set to x86. They didn't match.

After setting the test setting Architecture back to x64 and rebuilding, all tests were discovered again.

Answer 7

For me, the issue was that I mistakenly placed test cases in an internal class

[TestClass]
internal class TestLib {
}

That was causing test cases not being identified.

Answer 8

I had trouble with VS 2017 finding my UnitTest as well. It wasn't the exact problem John was asking - but this was the first result in google that I came looking for so I wanted to share my issue.

I had a legacy solution coming back from VS2010 going over VS2013, VS2015. Now in VS2017 it seems namespaces for the [TestMethod] Attribute have changed.

Before it was using

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

I created a new Test.dll in the project and that one used by default

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

So my solution was to create a new UnitTest project from within VS2017. Maybe changing assembly references for the old test project would have worked as well. With the new reference VS2017 did discover those unit tests.

Answer 9

Don't read out of date articles under MSDN. .NET Core relevant materials are under docs.microsoft.com

https://docs.microsoft.com/en-us/dotnet/articles/core/testing/

Generally speaking you need a .NET Core console app to contain the unit test cases.

Answer 10

Be sure that you are using the correct Microsoft.NET.Test.Sdk:

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />

Do not use pre-release ones. Or you have to change to console app (not library). I have the similar issue, but with the latest release (15.0.0), it starts working again.

Also, you may have to add:

<ItemGroup>
  <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>

but I do not think it is nessesary.

Answer 11

I know that OP has listed this on his checklist, but it's easy to overlook that point while doing clean install of Visual Studio 2017 and setting up new project. Apart from NUnit project template and NUnit Framework one needs to install NUnit adaptor separately, e.g. using NuGet command Install-Package NUnit3TestAdapter -Version 3.9.0. After that Visual Studio Community 2017 started discovering unit tests without any issues.

Answer 12

In my case the Test Explorer couldn't find my tests after I moved the project to a new solution.

The answer was simply that I had a reference to the old MS Test Adapter in my project.

I had a duplicate of the line below for version 1.1.11 of the MS Test Adapter in my cs.proj file:

<Import Project="..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props')" />

To fix the problem,

1. Right click on project and select 'Unload Project'.
2. Right click project and select 'Edit'
3. Remove line that imports old version of adapter.
4. Right click on project and select 'Reload Project'.
5. Rebuild Solution/Project

Answer 13

Just had this problem with visual studio being unable to find my tests, couldn't see the button to run them besides the method, and they weren't picked up by running all tests in the project.

Turns out my test class wasn't public! Making it public allowed VS to discover the tests.

Answer 14

For me was easier to create a new test project that works perfectly fine with Visual Studio 2017... and just copy the test files, add references, and NuGet packages as required.

Answer 15

Solution was removing my app.config file from my unit test project. The tests will re-appear!

This file referenced some dll's in the bindingredirects that were not actually present in the project references. Re-add the assemblybindings that are strictly necessary for your project.

Answer 16

I was facing the same issue, in my case in order to resolved

1. I opened the windows console (windows key + cmd).
2. Navigate to the folder where the project was created.
3. Executed the command "dotnet test" it is basically the same test that visual studio executes but when you run it thru console it allows you to see the complete trace.
4. I got this error message "TestClass attribute defined on non-public class MSTest.TestController.BaseTest"
5. So I went to the test case and mark it as public, build again and my tests are being displayed correctly

Answer 17

In my case, it was a project I had upgraded the test project from an earlier .NET version. in the app.config I had assemblybindings to previous versions of the dependant assemblies.

After fixing the assembnlybindings in the app.config, my tests got discovered.

Answer 18

Discovery

The top answers above did not work for me (restarting, updating to version 1.1.18 ... I was already updated, deleting the temp files, clearning NuGet cache etc).

What I discovered is that I had differing references to MSTest.TestAdapter and MSTest.Framework in different test projects (my solution has two). One was pointed to 1.1.18 like...

packages.config

<package id="MSTest.TestAdapter" version="1.1.18" targetFramework="net461" />
<package id="MSTest.TestFramework" version="1.1.18" targetFramework="net461" />

... but another has the references to 1.1.11. Some of the answers above lead to this discovery when two versions of the libraries showed up in my temp directory (%TEMP%\VisualStudioTestExplorerExtensions\) after restarting Visual Studio.

Solution

Simply updating my packages.config to the 1.1.18 version is what restored my unit tests functionality in VS. It appears that there are some bugs that do not allow side-by-side references of the MSTest libraries. Hope this helps you.

More info:

• Visual Studio 2017 Ent: 15.5.6 (I had updated from 15.0.1 with hopes to fix this issue, but I had it in both)

Answer 19

In my case, it was UWP project present in the solution causing the issue.

When I unloaded the UWP project, tests were discovered. When I loaded it back, test disappeard again.

Try to unload all projects and keep test project only. Ten rebuild solution and test shound appear in Test Runner. Load projects one by one and rebuild solution each time to find out what project are causing the problem

sample repo

VS bug report

Answer 20

The Issue

The problem is that Visual Studio is getting 'confused' over the dotnet core versions on the machine. When I went to control panel -> uninstall programs I had 8 different dotnet core SDK's and Runtimes installed. This was somehow causing VS to silently have an error when trying to find tests.

Validate The Issue

You can validate the issue by going to the command line and getting the version of dotnet your on $ dotnet --version. If you see anything except the latest version you have installed then your machine has some mismatch and is not using the correct version. Example...If you have dotnet core 1.0.1 installed but when you get the version at command prompt and it says 1.0.0 thats a problem.

The Solution

Delete all the old stuff. I started with only what I though I needed to remove (the oldest dotnet rc versions) but it still gave the wrong version when testing the issue. Eventually I conceded to do a full clean. I...

• Uninstalled all visual studio applications (on my machine VS2015 and VS2017)
• Uninstalled all versions of dotnet core (even most recent)

After my machine was completely empty of all VS and donet I installed only VS2017 (it comes packaged with latest dotnet). I created a xUnit test project and the test explorer found the test immediately SOLVED

This may seem like overkill but I spent two weeks trying to fix this in other ways. If your having the issue just do it, even though it may take you hours to uninstall/reinstall items it will probably save you time.

References

• See @epestic blog post where he gives more detail on fixing the issue.

Answer 21

For C++:

As there is no special question for C++ tests, but the topic is very much the same, here is what helped me when I had the trouble with test discovery.

If you have only installed Desktop development with C++, then the solution is to also install Universal Windows Platform development with the optional C++ Universal Windows Platform tools. You can select these in the visual studio web installer.

Afterwards, rebuild your test project and the test discovery should work.

Btw, I created the unit test project in VS2017. It might be important, because some users mentioned, that they had discovery issues in projects, that were migrated from VS2015 to VS2017.

Answer 22

Removing old .dll should help. Clearing temp files located in the %TEMP% directory at C:\Users(yourusername)\AppData\Local\Temp

Answer 23

I had the same issue. My solution was OK but suddenly when I opened the solution I found out the tests are gone.

Finally I downgraded Microsoft.VisualStudio.TestPlatform.TestFramework and Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions packages to a very old version (using NuGet manager) and test methods showed up. Then I upgraded to latest version and still there were there.

So just downgrade and upgrade packages.

Answer 24

On my case none of the above help to me. But, i downgrade NUNit3TestAdapter to version 3.8.0, then upgrade to the latest (3.10.0)

Answer 25

Sometimes changing the namespace of the tests work. I had the folder structure as follows:

A |___B | |___D |___C___E

The namespace was flat like Tests.< name > and they did not show up in the test window. When I changed the namespace to the structure of the directory, all the tests showed up. Now I could revert back to any other namespace structure I want.

Do not forget to build your project!

Answer 26

In the case of .NET Framework, in the test project there were formerly references to the following DLLs:

Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions

I deleted them and added reference to:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

And then all the tests appeared and started working in the same way as before.

I tried almost all of the other suggestions above before, but simply re-referencing the test DLLs worked alright. I posted this answer for those who are in my case.

Answer 27

I've tried everything but nothing helped. In my case, I had a solution with several test projects and some of them were using the old ms-test framework so Visual Studio found only those.

I installed the test framework packages for all test projects as showed in this answer, then removed the references to the old quality-tools, restarted Visual Studio, and now I can see all tests.

Answer 28

For me, changing the TargetFramework in the test project's .csproj file from

<PropertyGroup>
  <TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>

to

<PropertyGroup>
  <TargetFramework>net46</TargetFramework>
</PropertyGroup>

worked.

Answer 29

At first, i've tried to use MSTest. After that, i change it to Nunit test. Then i wanted to back MSTest. I removed all nUnit codes and references but Test Explorer did not show MSTest methods. Solution: I removed all mstest nuget references and reinstalled. Done.

Answer 30

Sometimes, I find if you have stackoverflow exceptions in your unit test code, visual studio will mark that unit test case as not run and will stop running other test cases that follow this case.

In this case, you have to find out which case is causing the stackoverflow exception.