Encountering issues where the Visual Studio Test Runner isn’t discovering your xUnit v2 tests can be incredibly frustrating for any developer. This common problem, spanning Visual Studio 2015, 2017, and 2019, often halts development workflows and leaves you scratching your head. It’s not uncommon for tests that compile perfectly to simply vanish from the Test Explorer, making it impossible to run your crucial unit tests. This guide dives deep into the underlying reasons why the Visual Studio 2015/2017/2019 Test Runner is not discovering your xUnit v2 tests and provides actionable solutions to get your test suite back on track. We’ll explore everything from common configuration pitfalls to essential troubleshooting steps, ensuring you can efficiently identify and resolve these elusive discovery failures.

The Core Culprits: Understanding Test Discovery Mechanics

The Visual Studio Test Runner relies on a robust discovery mechanism to find and execute your unit tests. This process isn’t just about compiling your code; it involves specific components and configurations that allow the Test Explorer to identify test methods. At its heart, test discovery for xUnit.net hinges on the presence and correct functioning of the xUnit.runner.visualstudio NuGet package. This package acts as the crucial bridge, enabling the Visual Studio Test Explorer to recognize xUnit.net’s test patterns within your compiled assemblies.

When tests aren’t discovered, it often points to a breakdown in this communication chain. The Test Runner scans your project’s output directory for assemblies that contain test attributes and are compatible with its installed adapters. If the necessary xUnit test adapter isn’t present, is outdated, or if there’s a mismatch in the target framework between your test project and the adapter, discovery will fail silently. Understanding this fundamental process is key to diagnosing why the Visual Studio 2015/2017/2019 Test Runner is not discovering your xUnit v2 tests.

Furthermore, the build process itself plays a significant role. If your test project doesn’t build successfully, or if its output is somehow corrupted or placed in an unexpected location, the Test Runner simply won’t have anything to discover. This highlights the importance of a clean build environment and correctly configured project files, ensuring that the necessary DLLs, including those containing your tests and the xUnit adapter, are generated and accessible to Visual Studio’s test infrastructure.

Common Configuration Mismatches Preventing Test Discovery

Many test discovery issues stem from subtle yet critical misconfigurations within your project settings or the solution itself. These often go unnoticed during standard development but become glaring problems when the Test Runner fails to pick up your xUnit tests.

Target Framework Incompatibility

One of the most frequent reasons for the Visual Studio 2015/2017/2019 Test Runner not discovering your xUnit v2 tests is a mismatch in target frameworks. If your test project is targeting, say, .NET Framework 4.6.1, but your xUnit.runner.visualstudio package or other dependencies are compiled for a different version or for .NET Core, incompatibility can arise. Ensure that your test project’s target framework aligns with the version of the xUnit test adapter you’re using and, ideally, with the framework of the project it’s testing. This consistency is vital for the test discovery process to function correctly across different Visual Studio versions.

Build Configuration and Platform Issues

Incorrect build configurations can also hide your tests. Sometimes, developers might inadvertently set their test projects to build only in “Debug” mode, and then try to run tests while Visual Studio is configured for “Release.” Similarly, platform targets (Any CPU, x64, x86) must be consistent across your solution and the xUnit test adapter’s expectations. A common scenario is building a project for x64 but having the test runner look for x86 assemblies, or vice-versa. Always verify your active solution configuration and ensure your test project is set to build for the current configuration and platform. For instance, if you’re using a 64-bit operating system, ensuring your test projects are built for “Any CPU” or “x64” can resolve many discovery woes.

Missing or Outdated NuGet Packages

The xUnit.runner.visualstudio NuGet package is non-negotiable for test discovery within Visual Studio. If this package is missing from your test project, or if it’s severely outdated, the Test Runner simply won’t have the necessary components to find your xUnit tests. Always ensure you have the latest stable version of this package installed in your test project. Furthermore, dependencies like xunit (the core xUnit framework) and xunit.extensibility.core should also be up-to-date and consistent across your project. Outdated package references can lead to assembly conflicts that prevent the Test Runner from properly loading the test assemblies, causing the Visual Studio 2015/2017/2019 Test Runner not discovering your xUnit v2 tests dilemma.

Troubleshooting Steps for Test Discovery

When facing the persistent issue of the Visual Studio 2015/2017/2019 Test Runner not discovering your xUnit v2 tests, a systematic approach to troubleshooting is essential. These steps will help you isolate and resolve the problem efficiently.

1. Clean and Rebuild Your Solution: This is often the first and most effective step. Go to Build > Clean Solution, then Build > Rebuild Solution. This ensures all old build artifacts are removed and a fresh build is performed, which can resolve corrupted caches or stale binaries.

2. Verify NuGet Package Installation: Right-click your test project in Solution Explorer, select Manage NuGet Packages..., and ensure that xunit.runner.visualstudio is installed and up-to-date. Also, confirm the core xunit package is present. If it’s installed, try uninstalling and reinstalling it to force a fresh dependency resolution.

3. Check Output Window for Build Errors: After building, review the “Output” window (View > Output) and select “Build” from the dropdown. Look for any warnings or errors related to your test project or its dependencies. Even seemingly innocuous warnings can sometimes point to deeper issues preventing test assembly loading.

4. Restart Visual Studio: A simple restart can often clear internal caches and resolve transient issues that prevent the Test Runner from discovering tests. Close all instances of Visual Studio and reopen your solution.

5. Examine Test Explorer Output: In the Test Explorer window, look for a small “Output” link or pane. This can sometimes provide clues about why tests aren’t being Question & Answer :

   UPDATE: Adding a 2019; the discovery/runner integration mechanism is same as per 2017 & 2015, so the key things that can go wrong are the same.

   ---

   I’ve read Why is the xUnit runner not finding my tests, which covers reasons xUnit would never be able to find your tests but my problem is different - I’m confident there’s nothing subtle going on with my tests; (they have worked in other environments, this seems to be just my machine) - the Visual Studio Test Runner in Visual Studio 2015 [Community Edition] is simply not showing any of my tests. I’m not doing anything remotely exciting; the tests target xUnit.net v2 on the Desktop.

   I’ve looked in the Output window and am not seeing anything in at all under Test in the Show output from tabs.

   1. Eliminate discovery exceptions from your inquiries; go to the output Window (Ctrl-Alt-O), then switch the show output from dropdown (Shift-Alt-S) to Tests and make sure there are no discovery exceptions
   2. Test|Test settings|Default processor architecture can help if your tests are x86/x64 specific and discovery is triggering bittedness-related exceptions, i.e. not AnyCpu
   3. As suggested in this answer(upvote it if the technique helps) running the desktop console runner (instructions) can be a good cross check to eliminate other possibilities, e.g. mangled config files:-

   > packages\xunit.runner.console.2.2.0\tools\xunit.console <tests.dll> 
   

   NOTE The xunit.runner.console package is deprecated - when you get stuff working in VS, you’ll be able to have dotnet test run them in CI contexts too

   ---

   Go read the documentation - it’s comprehensive, up to date, includes troubleshooting info and takes PRs:-

   Important note: If you’ve previously installed the xUnit.net Visual Studio Runner VSIX (Extension), you must uninstall it first. The Visual Studio runner is only distributed via NuGet now. To remove it, to go Tools > Extensions and Updates. Scroll to the bottom of the list, and if xUnit.net is installed, uninstall it. This will force you to restart Visual Studio.

   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).

   The following steps worked for me:

   1. (Only if you suspect there is a serious mess on your machine - in general the more common case is that the visual studio integration is simply not installed yet)

   Do the DEL %TEMP%\VisualStudioTestExplorerExtensions as advised :-

   PS> del $env:TEMP\VisualStudioTestExplorerExtensions 
   

   1. Install the NuGet Package xunit.runner.visualstudio in all test projects

      • Paket:

        .paket\paket add nuget xunit.runner.visualstudio -i 
        

        You need to end up with the following in your paket.dependencies:

        nuget xunit.runner.visualstudio version_in_path: true 
        

        Note the version_in_path: true bit is important

      • Nuget: Go to Package Manager Console (Alt-T,N,O) and

        Install-Package xunit.runner.visualstudio 
        

      Rebuild to make sure xunit.runner ends up in the output dir

   2. Close Test Explorer <- this was the missing bit for me

   3. Re-open Test Explorer (Alt-S,W,T)

   4. Run All tests (Ctrl R, A)