Visual Studio 2013 doesn't discover unit tests

C#.Net Visual Studio Unit Testing Visual Studio-2013

C# Problem Overview

I have a simple solution in visual studio 2013 that is composed by one web project, one library project and one unit test project. When I open the solution and try to run the unit tests they are not discover by visual studio. To run the tests I try to go to the menu and choose Test -> Run -> Run all tests or by opening the test explorer window. By those to methods visual studio doesn’t discover any tests in the solution.

Creating first a simple unit tests project and try to run the test, visual studio know discover the test and I can run it. Then, if I open my previous solution visual studio now discovers all the tests. I try to save my solution but closing it and reopening, without creating a unit test project first, the visual studio doesn’t find the tests again. This is a very strange behave that I don’t know why this is happening.

I used to working alone in this project that was using the source control git integrated with the visual studio team foundation. The problem of visual studio not discover the unit tests start when a new element came to the project and when I need to recreate the solution through the source control online. Before this, all tests always been discovered by visual studio.

For creation the unit tests I use the dll Microsoft.VisualStudio.QualityTools.UnitTestFramework. My version of visual studio is: Microsoft Visual Studio Express 2013 for Web Version 12.0.30723.00 Update 3. My version of .net framework is 4.5.50938.

All of my tests are like this:

[TestClass] 
public class Service1Test 
{ 
    [TestMethod] 
    public void Test1() 
    {
        Assert.IsTrue(True); 
    } 
}

C# Solutions

Solution 1 - C#

Some things I've noticed I have to do from time to time to get tests to show up properly.

If your solution is in a protected drive that you need administrator access to read/write, sometimes only a portion of the tests come up. Definitely run VS as administrator in that case.
If your solution is 64 bit, make sure that Test > Test Settings > Default Processor Architecture is set to x64. Sometimes it gets set to x86. Set it to x64, then rebuild.
Sometimes just restarting Visual Studio does the trick because the test explorer will start up again.
Don't forget to actually build the test project/solution. (If you want it to get built with the rest of the projects, right-click on your solution > Properties > Configuration Properties > Configuration > check the "Build" box for your test project)
Ensure the tests are in a public section of your test class

Solution 2 - C#

If you using NUnit, make sure to download NUnit Adapter first.

Go to Tools → Extensions and Updates… → Online → search for "NUnit Test Adapter".

Solution 3 - C#

Make sure your test class is public so it can be found. And if you're referencing another class, make sure of the same.

Also, sometimes if you have no Asserts or you're not decorating the test with a [TestMethod], a test might not be recognized.

2 more things:

Async unit tests act funny at best, and none at all at worst. Have a look at this article by Stephen Cleary and keep from there if it interests you.
If you use NUnit and you run into the same issues, keep in mind it's [TestCase] for Nunit, instead of [TestMethod]

Having said the above, here's an article I've posted on the code project, with both MSTest & NUnit, in case you want to give it a spin and make sure you're not missing anything.

Solution 4 - C#

I had the same issue but none of the other solutions worked. Turns out that I was using the NUnit 3 framework with the 2 adapter.

If you're using NUnit 3, go to Extensions and Updates and install the NUnit3 Test Adapter.

Solution 5 - C#

I'm having this issue from time to time. What works for me is to shutdown Visual Studio and go to folder:

%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache

and delete it content.

Once you open Visual Studio and load your project again Test Explorer should contain back your tests

Solution 6 - C#

XUnit users may notice Test Explorer window no longer lists any tests. To make tests discoverable again try this important tip, highlighted below.

> If you're having problems discovering or running tests, you may be a victim of a corrupted runner cache inside Visual Studio. To clear this cache, shut down all instances of Visual Studio, then delete the folder %TEMP%\VisualStudioTestExplorerExtensions. Also make sure your project is only linked against a single version of the Visual Studio runner NuGet package (xunit.runner.visualstudio).

Solution 7 - C#

For future googlers I had a rare scenario that caused this.

On my base test class I had a property named TestContext. This interfered with MSTest's reserved TestContext property causing all my tests to be hidden from VS/Resharper except one (which did not inherit from the base).

Solution 8 - C#

for me it was changing 'solution configurations' to Debug (instead of Release).

Solution 9 - C#

My problem was because my unit test method wasn't void, and it was receiving parameters.

Solution 10 - C#

I have found that unit test methods marked as async void aren't discovered by the VS Test Explorer. This seems to be because VS would not have any way to wait for a test to finish and decide if it succeeded or not. If you absolutely need to have a test method to run asynchronously then get it to return a Task instead like async Task. I found that this fixed the issue for me.

Solution 11 - C#

Try building all projects as MSIL (Any CPU) instead of x86/x64. Worked for me strangely

Solution 12 - C#

While AndyG's solution works, a more lasting solution could be to set the PreferredToolArchitecture environment variable to "x64", either by:

https://stackoverflow.com/questions/19820718/how-to-make-visual-studio-use-the-native-amd64-toolchain

or by:

Control Panel | System and Security | System | Advanced System Settings|Environment Variables
PreferredToolArchitecture = x64
DefaultToolArchitecture = Native64Bit
PROCESSOR_ARCHITECTURE = x64
ProcessorArchitecture = x64

Solution 13 - C#

I was facing the same problem and I've remembered, again (this situation happened before), that selecting "Mixed Platform" on the solutions platform menu works, as well as the other answers.

Solution 14 - C#

I'd managed to add mine as

public static void TestMethod1(){}

started working once I removed static....

Solution 15 - C#

Go to Nuget package manager and download Nunit Adapter as follow.

Solution 16 - C#

go to the project menu > Configuration Manager check your test project platform matches the rest of the project and is check to build then rebuild.

Solution 17 - C#

Just ran into this as well as I didn't see a similar case that was similar to mine.

In the .csproj file of my test project, NUnit reference privacy was set to False:

<Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
  <HintPath>..\packages\NUnit.2.6.4\lib\nunit.framework.dll</HintPath>
  <Private>False</Private>
</Reference>

After I set <Private> to True it worked.

Solution 18 - C#

You just need to install this package only:

NUnit TestAdapter

Solution 19 - C#

To get tests to show in the Test Explorer Window I had to install NUnit3 Test Adapter 3.0 which was not available in Package Manager.

Downloaded from https://visualstudiogallery.msdn.microsoft.com/0da0f6bd-9bb6-4ae3-87a8-537788622f2d

Solution 20 - C#

I had the exact same problem.

It was due to incompatible version of NUnit I'd added to my project (3.2.0) and the Test Adapter I had installed (2.0.0).

To fix, use "Tools > Extensions and Updates" and search for NUnit3 Test Adapter, it discovered my tests after that.

Cheers

Solution 21 - C#

Let's just say for argument's sake that you need to use X64 architecture on your test project in order for the dependencies to build properly (as in my case). You may need to modify your Default Processor Architecture under the Test--Test Settings menu. Setting this to X64 allowed my test explorer to find my tests using Microsoft.VisualStudio.TestTools.UnitTesting.

Solution 22 - C#

Sorry for adding to the long list, but I had a completely a different problem. First, I would like to mention I discovered my issue when clicking 'Run All' in the Test Explorer and then watching the build output window in Visual Studio. You have to actively watch it, as afterwards the message disappears.

As for the issue, it looks like during the scanning of the tests, the DLL gets loaded and its test types are enumerated. This causes the references to be loaded and if any failure occurs during this process, the tests will not be shown in the explorer. I had two issues preventing the test DLL to be successfully loaded:

There was still a binding redirect left in the config file (redirecting to a version lower version NHiberate than what was referenced in the test project).
A conflicting assembly reference (2nd level references not being able to load). AsmSpy is btw a great tool to hunt for these.

Solution 23 - C#

If you load a Visual Studio (VS 2015 Community in my case) solution from a network share or My Documents directory that is part of a share, you will get into this trouble. I solved it by moving the solution and its underlying projects to a local folder.

Solution 24 - C#

After spending 2 days... none of the above worked for me. The only "solution" was: Go to project properties -> Build Tab. Then click Advanced button on the right bottom corner of the pane. Change "Debug Info:" to "full" and click OK.

Here are the screen shots:

Solution 25 - C#

I came across the same issue. And investigated and found that the dll's were not build, and put in the right folder. as soon as I changed my configuration they appeared.

the Projects build options, what folder should be used?
the build menu entry build configuration, they should be checked.

that fixed it for me.

Solution 26 - C#

For the Visual Studio 2013.5, clearing the \TestResults directory in the solution helped. Visual Studio corrupted the mdf file in which it stores the discovered tests, thus preventing the discovery of unit tests.

Solution 27 - C#

Be sure your all projects are runing with the same configuration. Under your project's Properties => Debug => Platform in drop down list choose the appropriate platform (for me it was "Any CPU") as determined at your other projects.

Solution 28 - C#

I know that the unit tests are not found if the solution is not built, so that is something to try (Build the solution), but that solution is like the help desk asking if your computer is plugged in...
After a clean rebuild did not fix the problem for me, running a full batch build did fix it.

Solution 29 - C#

Had the same issue; tests suddenly stopped being discovered.

Nunit Test Adapter had become disabled somehow. Clicking enable in the extension manager fixed it for me.

Solution 30 - C#

I had the same problem until I realized I made a cut/paste error and left off [Test Method] before the test.

Solution 31 - C#

In my case the problem was because my class was marked as abstract.

Just remove the abstract keyword.

Solution 32 - C#

Another solution:

Open a command prompt, type set, and verify if PROCESSOR_ARCHITECTURE is set correctly, change to x86 or AMD64 if needed.

source: https://connect.microsoft.com/VisualStudio/feedback/details/873170/vs2012-vstest-console-exe-error-incompatible-target-platform-settings-x86-with-system-architecture-arm-occurs-when-processor-architecture-is-not-set

Solution 33 - C#

I had the same problem with my tests on TFS 2015. The problem I had was my test did not show up anymore. the test adapter could not find any tests. I removed all references for Microsoft.VisualStudio.QualityTools.UnitTestFramework and now they show up again. I hope my answer help someone

Solution 34 - C#

I had a similar issue to this with Visual Studio 2015. As soon as I made an async Task unit test Visual Studio would start having problems discovering it, finding the source for it, and it wouldn't allow me to debug it.

It turns out that there is a bug with PostSharp which causes this behaviour, and the test project I was using had PostSharp enabled.

The solution in my case was to disable PostSharp for the unit test project, by putting the following in the <PropertyGroup> element a the beginning of the csproj project file:

<SkipPostSharp>True</SkipPostSharp>

Solution 35 - C#

In my case, I updated NUnit from 2.X to 3.X after what the driver stopped to go into [SetUp]. I tried to install NUnit 3 adapters from NuGet, but it did not help. Then I uninstalled my then current version on TestDriven (3.8) and installed 3.10 instead. It started to work (again).

Solution 36 - C#

Make sure the project is marked as test project. You can do that by adding the below xml to the csproj project file.

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

Solution 37 - C#

In my case, I had to update two NuGet Packages.

MSTest.TestAdapter
MSTest.TestFramework

Solution 38 - C#

Had the same problem on a legacy project using VS2008. In the test output window, it kept printing that the unit test DLL was not a Nunit Test. I'm using the plugin NunitForVS by-the-way from https://archive.codeplex.com/?p=nunitforvs and yes I have followed the instructions and added the ProjectTypeGuids to the proj file.

Turned out that the NunitSettings.xml file in the folder \Users<user>\AppData\Roaming\Nunit\ was empty.

I copied the mirrored file from the \Users<user>\AppData\local\Nunit\ folder which looked complete and even without restarting Studio it started rediscovering the Nunit tests.

Hope this helps somebody.

Content Type	Original Author	Original Content on Stackoverflow
Question	miguelbgouveia	View Question on Stackoverflow
Solution 1 - C#	AndyG	View Answer on Stackoverflow
Solution 2 - C#	Farukh	View Answer on Stackoverflow
Solution 3 - C#	Noctis	View Answer on Stackoverflow
Solution 4 - C#	Frank	View Answer on Stackoverflow
Solution 5 - C#	Mariusz Gorzoch	View Answer on Stackoverflow
Solution 6 - C#	SushiGuy	View Answer on Stackoverflow
Solution 7 - C#	AdamB	View Answer on Stackoverflow
Solution 8 - C#	zook2005	View Answer on Stackoverflow
Solution 9 - C#	alansiqueira27	View Answer on Stackoverflow
Solution 10 - C#	cookiemonster	View Answer on Stackoverflow
Solution 11 - C#	Alfons	View Answer on Stackoverflow
Solution 12 - C#	empty	View Answer on Stackoverflow
Solution 13 - C#	Jeferson	View Answer on Stackoverflow
Solution 14 - C#	Arthur Russell Fox	View Answer on Stackoverflow
Solution 15 - C#	Debendra Dash	View Answer on Stackoverflow
Solution 16 - C#	user5224229	View Answer on Stackoverflow
Solution 17 - C#	Kevin Giszewski	View Answer on Stackoverflow
Solution 18 - C#	Sandy_Vu	View Answer on Stackoverflow
Solution 19 - C#	Mikal Madsen	View Answer on Stackoverflow
Solution 20 - C#	Francis Smith	View Answer on Stackoverflow
Solution 21 - C#	Dominic Hartjes	View Answer on Stackoverflow
Solution 22 - C#	Martijn Evens	View Answer on Stackoverflow
Solution 23 - C#	Ton Snoei	View Answer on Stackoverflow
Solution 24 - C#	curiousBoy	View Answer on Stackoverflow
Solution 25 - C#	kfn	View Answer on Stackoverflow
Solution 26 - C#	MartijnK	View Answer on Stackoverflow
Solution 27 - C#	Roni	View Answer on Stackoverflow
Solution 28 - C#	amalgamate	View Answer on Stackoverflow
Solution 29 - C#	HeatherD	View Answer on Stackoverflow
Solution 30 - C#	forforf	View Answer on Stackoverflow
Solution 31 - C#	glautrou	View Answer on Stackoverflow
Solution 32 - C#	Alfons	View Answer on Stackoverflow
Solution 33 - C#	Joerg	View Answer on Stackoverflow
Solution 34 - C#	Adam Goodwin	View Answer on Stackoverflow
Solution 35 - C#	Alex Konnen	View Answer on Stackoverflow
Solution 36 - C#	DonO	View Answer on Stackoverflow
Solution 37 - C#	Magic Mike	View Answer on Stackoverflow
Solution 38 - C#	Nick	View Answer on Stackoverflow