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.

I found out that VS2017 does not install all required packages. When I tried to move my MonoGame from old PC to new one with freshly installed windows 10 and VS 2017 it started throwing weird errors about missing packages. After installing VS2015 alongside with VS2017 all problems were gone. Maybe try to install VS2015 additionaly. — mrogal.ski, Mar 17 '17 at 15:56
I'm looking into if VS 2017 has all the environment variables correctly set. — John Pezzanite, Mar 17 '17 at 16:37
For NUnit, you must use the NuGet package for the adapter and it must be 3.8.0-alpha1 or newer. — Rob Prouse, May 23 '17 at 18:35
In my case it was the mere presence of an `app.config` file in my test project: https://stackoverflow.com/a/47497668/67824. — Ohad Schneider, Nov 26 '17 at 15:23
In my case just doing a solution re-build was enough for NuGet to restore the missing packages. What it was wrong in my case is that the Testing environment was set to x86 and setting this to x64 let the unit tests run. Go to Test -> Test Settings -> Default Processor Architecture -> x64 (if your are running the unit tests on a x64 CPU architecture). Hope this is helpful. — Adrian Chiritescu, Jul 09 '18 at 10:40
The path to %TEMP% is "generally" at C:\Users\(yourusername)\AppData\Local\Temp — Prisoner ZERO, Sep 04 '18 at 16:08
I deleted all files in my %TEMP% folder and it worked. I didn't have any VS test cache files. — shahista inamdar, Sep 21 '18 at 11:51
I found 2 versions of the test adapter in my temp folder - extensions. The output from the build showed the test adapter was called but never showed which version was used and nothing showed up in the test explorer. deleteing them both was enough for the project to restore only the latest version and then a rebuild populated my tests. — plyawn, Mar 31 '19 at 17:49

score 200 · Answer 1 · answered Jun 02 '17 at 23:37

200

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:

answered Jun 02 '17 at 23:37

Quality Catalyst

6,531
8
38
62

I was experiencing the same issue with a Web API 2 project and this worked for it. – Narthring Jul 06 '17 at 20:21
4

This helped me too! Note that you can "Manage Nuget Packages" at a solution level and do this for all the projects where this is required. You might then get "ambigous reference" errors - for these, just remove the old DLL (Microsoft.VisualStudio.QualityTools.UnitTestFramework) from references – Prashanth Subramanian Jul 20 '17 at 20:48
57

These things should be extensions of Visual Studio, not NuGet packages. – Jaider Aug 07 '17 at 03:10
1

We have a lot of old MSTest projects, and I wasn't aware it moved to a NuGet package. This solved it for me as well, originally thought it was a bug with the newer releases of ReSharper until I realized the VS Test Explorer also could not discover my tests. – David Anderson Oct 08 '17 at 03:59
Guys, to make it work, I had to install xunit.runner.visualstudio nuget package. Without that, it won't run and will always say that it can't find the tests. WTF? – Luis Abreu Nov 13 '17 at 08:36
I ran Resharper's "Optimize References" command against my unit tests. It removed MSTest.TestAdapter from the project. Adding it back in fixed me. – Larry Smith Jan 22 '18 at 21:46
re xunit, https://stackoverflow.com/questions/35103781/why-is-the-visual-studio-2015-2017-test-runner-not-discovering-my-xunit-v2-tests/35103782#35103782 – Ruben Bartelink Feb 14 '18 at 23:09
Well, upgrade helped. For a while. Then tests disappeared again, but the NuGet package is already up to date. Now what?... – C-F Feb 21 '18 at 05:42
1

I did the exact same thing as this answer states. In my VS2017 solution, I added an MSTest project, added a few tests, but building the solution would result in: Discover test finished: 0 found. So, for the test project, in NuGet Package Manager (you can also do at solution level), I updated the MSTest.TestAdapter and MSTest.TestFramework both from v1.1.18 to v1.2.0. Then, after doing a build, my tests now appear in Test Explorer. – Kershaw Feb 24 '18 at 03:09
1

Worked great for me I had to go into the nuget package manager in VS2017 for the particular test project and simply updated the various packages I had like nunit etc then build > rebuild and all okay. – Trevor Sep 28 '18 at 21:30

score 130 · Answer 2 · answered Oct 02 '17 at 19:24

130

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.

answered Oct 02 '17 at 19:24

PmanAce

4,000
2
24
29

5

This worked once, not afterwards. What (this time) fixed it for me was deleting TestResults folder and bin/obj (along with this temp directory cleanup) – icesar Jan 30 '18 at 18:33
24

Anyone that wonders where `%TEMP%` - bring command window and type `echo %TEMP%` – mike123 Feb 02 '18 at 17:19
27

Folder doesn't exist in temp :/ – Douglas Gaskell Feb 24 '18 at 22:31
so what is the cause of such behavior? – Mykhailo Seniutovych Feb 28 '18 at 11:03
My case was changing workspaces had corrupted something. – PmanAce Feb 28 '18 at 12:41
1

Easiest way to access %TEMP% is to win+R and type %TEMP% – PontiusTheBarbarian Apr 09 '19 at 10:37
@mike123 or just `cd %TEMP%`. – phoog Dec 14 '20 at 16:38
VisualStudioTestExplorerExtensions didn't exist in %TEMP%, but there were a bunch of folders with names starting with VS. I just closed VS, deleted all of those, restarted VS, clean built, and voila. – DCShannon Aug 09 '23 at 17:50

score 60 · Answer 3 · edited Jan 07 '21 at 00:40

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.

Targeting .NET Framework rather than .NET Standard worked for me. Thanks. — Ben Griswold, May 18 '17 at 16:39
That Microsoft.NET.Test.SDK reference was missing in my project and there was no indication anywhere that anything relied on it to display. Added it via the nuget console and everything started working. Thanks for the reference listing! — GWhite, Aug 08 '17 at 02:12
I had to copy this folder from a coworker to my temp directory and restart VS: %TEMP%\VisualStudioTestExplorerExtensions\MSTest.TestAdapter.1.1.18 — Heiner, Aug 22 '17 at 08:03
How can I test a netstandard 2.0 project if I change my Target Framework ? I cannot compile anymore because a project netstandard2.0 cannot be referenced by a project that tagets net46 — Jerome2606, Dec 28 '17 at 14:07
@Jerome2606 your unit tests can target net461 or netcore20. See https://learn.microsoft.com/en-us/dotnet/standard/net-standard — Rob Prouse, Dec 28 '17 at 14:32

score 59 · Answer 4 · edited Jan 07 '21 at 00:41

59

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.

edited Jan 07 '21 at 00:41

Pang

9,564
146
81
122

answered Nov 29 '17 at 14:19

kidroca

3,480
2
27
44

7

not sure why down voted, but before my morning coffee 100% this was overlooked by me. – Andrei Dec 11 '17 at 12:29
1

Tried all other answers to this question/problem and this was the one that finally worked! – FastTrack Aug 03 '18 at 18:36
3

That one is incredibly embarassing but.. whatever. The hilarious thing is that if you create a test suite case in VS2017 it will **not** generate the `public` class, but just the class, so it won't discover it until you add the `public` identifier. – briosheje Sep 04 '18 at 12:44
of course. my bad - mstest should have this feature. – Crismogram Oct 12 '18 at 20:54

score 42 · Answer 5 · edited Jan 07 '21 at 00:43

42

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.

edited Jan 07 '21 at 00:43

Pang

9,564
146
81
122

answered Apr 26 '17 at 15:00

Sanchal Kunnel

539
6
8

35

Deleting **%Temp%\VisualStudioTestExplorerExtensions** was enough for me. – Juan Pablo Gomez May 13 '17 at 17:46
Yeap. Just deleting that and restarting VS fixed it. – Juan Carlos Oct 16 '17 at 18:27
Does anyone know what causes this in the first place? I've had it happen twice to me now, but deleting that folder and restarting VS worked. It's just weird. – Scott Salyer Dec 11 '17 at 16:44
@PmanAce - I did, actually. I'm using two different TFS instances (one per project), so the workspace changes automatically when I switch projects. – Scott Salyer Dec 20 '17 at 18:48
deleting the folder, and adding the nuget `Microsoft.NET.Test.Sdk` seemed to work for me.. thank you StackOverflow. (.NET Framework WebApi 2 solution) – bkwdesign Mar 08 '18 at 13:50
Turned out the entry from 'Referenced Paths' section of the VS project, for our repository, had an entire set of Microfest dll hell files copied from earlier verrsions of .NET – Christian May 18 '20 at 11:30

score 11 · Answer 6 · edited Jan 07 '21 at 00:45

11

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.

edited Jan 07 '21 at 00:45

Pang

9,564
146
81
122

answered Nov 23 '17 at 11:19

MiguelSlv

14,067
15
102
169

in vs2017 the setting in from menu Test -> Test Settings -> Default Processor Architecture – IcyBrk Apr 19 '19 at 19:45

score 11 · Answer 7 · edited Jan 07 '21 at 00:46

11

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.

edited Jan 07 '21 at 00:46

Pang

9,564
146
81
122

answered Aug 30 '18 at 12:34

TARJU

1,785
1
14
16

score 8 · Answer 8 · answered Jun 16 '17 at 10:45

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.

Sadly even a new unit test project doesn't have it's test show up for me :/ — Douglas Gaskell, Feb 24 '18 at 22:39

score 7 · Answer 9 · answered Mar 17 '17 at 18:52

7

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

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

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

answered Mar 17 '17 at 18:52

Lex Li

60,503
9
116
147

Thanks much, Lex. If this article is correct, the only way to test .NET Core is from the command line -- thus loosing all the VS integration we had with running tests in VS 2015. Am I correct in this? – John Pezzanite Mar 17 '17 at 20:19
Do you use xUnit.net or MSTest? – Lex Li Mar 17 '17 at 21:08
@JohnPezzanite you have to show more of what you did (probably a GitHub repo if possible). I do have projects at GitHub which works flawlessly, and many others also. – Lex Li Mar 18 '17 at 11:28
Follow the example in the line I supplied. I have tried it with .NET standard and .NET Core, with Microsoft's unit tests as in the example and with xUnit. .NET standard integrates with VS 2017 while .NET Core will only run from the command line. But I'm repeating what I've stated above. It sounds like Microsoft has removed all .NET Core unit test integration form VS 2017. – John Pezzanite Mar 18 '17 at 17:49
@JohnPezzanite test https://GitHub.com/lextm/sharpsnmplib and its NetStandard solution. – Lex Li Mar 18 '17 at 19:01
Thanks for shareing the example, Lex. At this point, I think we are talking past each other. The samples you supplied are .NET Standard (from your solution: netstandard1.3 . I am referring to .NET Core (from my solution file: netcoreapp1.1). – John Pezzanite Mar 19 '17 at 17:05
We started this conversation stating that the CLI works for .NET Core. I am not referring to the CLI but the IDE. VS 2015 seems to have a feature that VS 2017 does not. I am talking about IDEs not CLI. I am talking about .NET Core not .NET Standard. I have never said the .NET Core CLI did not work, nor that .NET Standard in the IDE did not work. My question is about .NET Core in the new IDE. – John Pezzanite Mar 19 '17 at 17:05
I am out of words. Have you even made a simplest test and then draw a conclusion. Why I can easily get a .NET Core (not .NET Standard) project with unit testing working in just a few minutes? https://www.dropbox.com/s/nyt4efmrue4sm36/ClassLibrary1.zip?dl=0 – Lex Li Mar 20 '17 at 00:31
@LexLi: I've tried your ClassLibrary1.zip and it worked. I created exactly the same XUnitTestProject1 in my solution and it does not work - tests are not discovered. – Liero Mar 31 '17 at 11:07
I also noticed, that if I change Active Solution Plafrom from "Any CPU" to x86 or x64 in your solution, the tests are not discovered. When I change it back, they're back again. It does not work in my solution, however... Trying to reproduce minimal repo, but I can not get it "not working" :) – Liero Mar 31 '17 at 11:17
here's minimal solution where tests are not discovered: https://developercommunity.visualstudio.com/storage/attachments/4036-bugreport.zip – Liero Mar 31 '17 at 12:52
@Liero I downloaded your minimal solution, opened it in Visual Studio 2017, did a rebuild and the tests appeared in Test Explorer for me. You are either doing something wrong, or there is an issue with your installation of Visual Studio. Open your output window and after building, switch the dropdown from Build to Tests and see if there are any errors reported in test discovery or if Test Discovery even happened. You should see a line Discover test started followed by XUnit output. – Rob Prouse May 17 '17 at 14:24
Most probably, they've fixed it already: https://developercommunity.visualstudio.com/content/problem/38369/net-core-tests-are-not-discovered-when-uwp-project.html – Liero May 18 '17 at 13:28

score 7 · Answer 10 · edited Jan 07 '21 at 00:47

7

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.

edited Jan 07 '21 at 00:47

Pang

9,564
146
81
122

answered Apr 04 '17 at 02:18

Alex Altotsky

109
2

What file is this located in? I can find the "Service Include" part in my project (*.csproj) file but not the PackageReference. – Chris Bennet Apr 04 '17 at 17:12
@ChrisBennet in your *test.csproj file. – Evgeni Nabokov Jun 06 '17 at 17:25
1

@evgeni-nabokov is right. All these changes are in the [project].test.csproj file. Right-click on the project in solution and select "Edit [project].test.csproj" See example at: https://github.com/RenetConsulting/angularcore.net/blob/master/Business/Application.Business.Test/Application.Business.Test.csproj – Alex Altotsky Jun 26 '17 at 04:26

jnt · Answer 11 · 2020-05-04T16:31:42.747

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,

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

Had the same issue. Removing and rebuilding solution didn't work. Restarted VS and tests were discovered! — Mike Ward, Sep 28 '17 at 23:59

score 5 · Answer 12 · answered Jan 29 '18 at 14:19

5

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.

answered Jan 29 '18 at 14:19

Marcin Tarsier

192
2
9

1

This helped me! – YvesR Jun 06 '18 at 14:24
OMG, this one did it for me. If I could drench you with bounties, I would. – Ash Jan 31 '19 at 01:22
This was the only solution that worked for me, thanks! – Vadim Tofan Jul 02 '19 at 10:26

score 4 · Answer 13 · answered Aug 29 '18 at 15:04

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.

score 2 · Answer 14 · answered Aug 07 '17 at 03:28

2

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.

answered Aug 07 '17 at 03:28

Jaider

14,268
5
75
82

creating new project probably saved hours of headache! – M.kazem Akhgary Nov 19 '18 at 19:12

Henrik Gering · Answer 15 · 2022-08-14T19:25:11.360

2

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 assemblybindings in the app.config, my tests got discovered.

edited Aug 14 '22 at 19:25

answered Dec 08 '17 at 11:19

Henrik Gering

1,769
16
29

score 2 · Answer 16 · edited Jan 07 '21 at 00:49

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)

score 2 · Answer 17 · answered Jun 25 '18 at 07:56

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.

score 2 · Answer 18 · answered Nov 29 '19 at 09:48

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

I opened the windows console (windows key + cmd).
Navigate to the folder where the project was created.
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.
I got this error message "TestClass attribute defined on non-public class MSTest.TestController.BaseTest"
So I went to the test case and mark it as public, build again and my tests are being displayed correctly

score 1 · Answer 19 · answered Mar 31 '17 at 12:52

1

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

answered Mar 31 '17 at 12:52

Liero

25,216
29
151
297

Appreciate the response but this is not my issue. If you look at the example repo I linked to in my question there is only a single project in the solution. There are not other projects to remove. That solution is a test though so I did try what you said unloading projects on my actual solution but it did not work. – rayepps Mar 31 '17 at 18:12

rayepps · Answer 20 · 2017-04-03T16:37:32.460

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.

score 1 · Answer 21 · edited Jan 07 '21 at 00:51

1

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.

edited Jan 07 '21 at 00:51

Pang

9,564
146
81
122

answered Aug 18 '17 at 09:21

t3chb0t

16,340
13
78
118

score 1 · Answer 22 · edited Jan 07 '21 at 00:52

1

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.

edited Jan 07 '21 at 00:52

Pang

9,564
146
81
122

answered Sep 21 '17 at 15:49

JDawg

8,560
4
25
29

FLICKER · Answer 23 · 2018-06-04T16:33:33.687

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.

score 1 · Answer 24 · answered Mar 03 '18 at 17:28

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.

score 1 · Answer 25 · answered Apr 04 '18 at 09:05

1

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

answered Apr 04 '18 at 09:05

Tanya Fomenko

61
3

score 1 · Answer 26 · answered Aug 20 '18 at 09:22

1

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)

answered Aug 20 '18 at 09:22

vlatko606

909
1
13
21

score 1 · Answer 27 · answered Dec 20 '18 at 03:17

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!

score 1 · Answer 28 · answered Jun 18 '19 at 08:44

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.

score 1 · Answer 29 · answered Sep 27 '22 at 16:46

1

Make sure your test class and method are NOT static.

answered Sep 27 '22 at 16:46

Gang

418
5
7

score 0 · Answer 30 · answered Sep 06 '17 at 13:06

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.

score 0 · Answer 31 · edited Jan 07 '21 at 00:53

0

In my case, the problem was that the project type was set to static library (lib), and it should be a dynamic library (dll).

edited Jan 07 '21 at 00:53

Pang

9,564
146
81
122

answered Sep 20 '18 at 16:52

Slate

3,189
1
31
32

score 0 · Answer 32 · answered Oct 18 '18 at 13:41

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.

score 0 · Answer 33 · answered Dec 20 '18 at 10:41

0

Check if the NUnit 3 Test Adapter is enabled. In my case, I already installed it a long time ago, but suddenly it got disabled somehow. Took me quite a while before I decided to check that part...

answered Dec 20 '18 at 10:41

Tybs

512
4
23

score 0 · Answer 34 · answered Feb 15 '19 at 16:53

0

I deleted the BIN and OBJ folders for the project. Once I did that, everything worked properly.

answered Feb 15 '19 at 16:53

Ctznkane525

7,297
3
16
40

score 0 · Answer 35 · answered Dec 11 '19 at 10:57

0

I had the same issue when migrating from Visual Studio 2017 to 2019. I had to reinstall Microsoft.NET.Test.Sdk in all my test projects.

answered Dec 11 '19 at 10:57

Melchia

22,578
22
103
117

score 0 · Answer 36 · edited Jan 07 '21 at 00:54

0

For me, I needed to run this, which updated all the nunit adapter links for the unit test projects:

Install-Package Nunit3TestAdapter

edited Jan 07 '21 at 00:54

Pang

9,564
146
81
122

answered May 28 '20 at 13:57

Brian

3,653
1
22
33

score 0 · Answer 37 · answered May 12 '21 at 11:16

0

I had to disable the (old) runsettings File.

answered May 12 '21 at 11:16

user1127860

150
2
14

score 0 · Answer 38 · answered Nov 11 '21 at 03:29

In my case it turned out that ONE of my test classes was not public. That prevented the entire suite from running.

BUT here is how I figured it out ==> It seems that the 'Output' console WILL show you the test logs. You just need to switch from Build to Tests.

This is embarrassingly simple. I hope my embarrassment can help someone else.

score 0 · Answer 39 · answered Mar 24 '22 at 17:58

In my case, it was that Test Explorer will exclude test methods if they are public async void (C#) or Public Async Sub X() (VB.NET).

Looking more closely at the messages in the Output window, Show output from: Tests, I saw this message:

if you are using async-await in test method then return-type must be Task. Example: public async Task Test.Class1.Test2()

Per the message, make sure all such methods return Task.

score 0 · Answer 40 · answered Jul 28 '22 at 11:17

0

Remember to decorate your class with <TestClass> or [TestClass], not just your methods.

answered Jul 28 '22 at 11:17

Le-roy Staines

2,037
2
22
40

score 0 · Answer 41 · answered Apr 20 '23 at 11:47

For me I found that the problem was being caused by the fact that the folder the solution had been created/cloned in contained a space. Once I closed the solution, changed the folder name and reopened the solution it was able to find and run the unit tests

Unit Tests not discovered in Visual Studio 2017

Update - Extend

What I've Tried

41 Answers41

Discovery

Solution

The Issue

Validate The Issue

The Solution

References

Linked

Related