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
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.
DEL %TEMP%\VisualStudioTestExplorerExtensions
Microsoft.DotNet.InternalAbstractions
(see SO post)test -> test settings -> default processor architecture
is set to x86The 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.
This question is related to
unit-testing
visual-studio-2017
I was facing the same issue, in my case in order to resolved
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.
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.
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.
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.
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,
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.
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.
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.
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.
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.
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:
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.
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.
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.
I deleted the BIN and OBJ folders for the project. Once I did that, everything worked properly.
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.
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!
I had the same issue and got it to work by doing the following:
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)
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.
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.
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.
Removing old .dll should help. Clearing temp files located in the %TEMP% directory at C:\Users(yourusername)\AppData\Local\Temp
For me, I needed to run this, which updated all the nunit adapter links for the unit test projects:
Install-Package Nunit3TestAdapter
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.
In my case, the problem was that the project type was set to static library (lib), and it should be a dynamic library (dll).
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.
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.
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.
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.
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...
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.
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.
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
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.
Source: Stackoverflow.com