Introduction

When Visual Studio fails to discover xUnit v2 tests, the problem is usually not xUnit itself but the connection between the test project and the Visual Studio test platform. In practice, discovery failures usually come from missing packages, an incompatible target framework, build failures, or stale test adapters.

Start with the Required Packages

For modern xUnit v2 test discovery in Visual Studio, the test project typically needs these packages:

• 'xunit'
• 'xunit.runner.visualstudio'
• 'Microsoft.NET.Test.Sdk'

A minimal SDK-style project file often looks like this:

1<Project Sdk="Microsoft.NET.Sdk">
2  <PropertyGroup>
3    <TargetFramework>net6.0</TargetFramework>
4    <IsTestProject>true</IsTestProject>
5  </PropertyGroup>
6
7  <ItemGroup>
8    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.10.0" />
9    <PackageReference Include="xunit" Version="2.9.0" />
10    <PackageReference Include="xunit.runner.visualstudio" Version="2.8.1">
11      <PrivateAssets>all</PrivateAssets>
12      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
13    </PackageReference>
14  </ItemGroup>
15</Project>

If Microsoft.NET.Test.Sdk or the xUnit Visual Studio runner package is missing, tests often compile but do not appear in Test Explorer.

Make Sure the Project Actually Builds

Visual Studio does not discover tests from a project that fails to build correctly. This seems obvious, but it is one of the most common causes because build errors may live in a different project in the same solution.

Before debugging discovery itself, run a build from the command line:

dotnet test

If dotnet test fails or reports no tests, fix that first. Test Explorer is not a better source of truth than the underlying test build and runner.

Check the Test Shape

A standard xUnit test uses attributes such as Fact or Theory.

1using Xunit;
2
3public class MathTests
4{
5    [Fact]
6    public void AddsTwoNumbers()
7    {
8        Assert.Equal(4, 2 + 2);
9    }
10}

If the class has no valid xUnit attributes, or the test project is not referencing xUnit correctly, Test Explorer has nothing to discover.

Old Adapters and Mixed Tooling Cause Confusion

Visual Studio 2015, 2017, and 2019 lived through several generations of test tooling. A project can end up with:

• old VSIX-based adapters
• NuGet-based adapters
• mixed MSTest, NUnit, and xUnit runner packages
• stale caches after target framework changes

That combination often leads to "works on the command line, not in Visual Studio" or the reverse. In general, prefer the NuGet-based xunit.runner.visualstudio package in the project and remove unnecessary legacy adapter assumptions.

Useful Recovery Steps

If the project file looks correct but discovery still fails, try this order:

1. clean and rebuild the solution
2. close and reopen Visual Studio
3. clear the bin and obj folders
4. restore packages again
5. confirm the target framework is supported by the installed tooling

These steps are boring, but they fix a surprising number of discovery problems because the issue is often stale build output rather than a logical mistake in the tests.

Solution-Level Noise Matters Too

Sometimes the test project is configured correctly, but the solution still misleads discovery because another project fails restore, target framework resolution, or package compatibility. Test Explorer works at the solution level often enough that solving unrelated build noise can be the step that finally makes the xUnit tests appear.

Common Pitfalls

• Referencing xunit but forgetting xunit.runner.visualstudio or Microsoft.NET.Test.Sdk.
• Debugging Test Explorer before confirming the project actually builds and dotnet test works.
• Mixing outdated adapter assumptions with current NuGet-based test discovery.
• Expecting tests to appear when the test methods are missing xUnit attributes such as Fact or Theory.
• Ignoring stale bin and obj output after changing frameworks, packages, or Visual Studio versions.

Summary

• xUnit v2 discovery in Visual Studio depends on the test SDK plus the xUnit Visual Studio runner package.
• Start by making sure the test project builds and dotnet test succeeds.
• Use Fact and Theory attributes so the runner has something to discover.
• NuGet-based test adapters are usually the right approach for these Visual Studio versions.
• Many discovery failures are stale tooling or package-configuration issues, not broken tests.