Skip to content
Latchkey

.NET "No test matches the given testcase filter" - xUnit/NUnit Discovery

dotnet test either matched zero tests against your --filter, or discovered none at all because the test SDK/adapter packages are missing. A filter typo skips everything; a missing adapter means the runner sees no tests to run.

What this error means

dotnet test exits with "No test matches the given testcase filter" or "No test is available in <assembly>. Make sure that test discoverer & executors are registered." The build succeeds but zero tests run.

dotnet test output
No test matches the given testcase filter `FullyQualifiedName~Smoke`
in /app/bin/Debug/net8.0/Tests.dll

# or:
No test is available in Tests.dll. Make sure that test discoverer &
executors are registered and platform & framework version settings are
appropriate.

Common causes

Filter matches nothing

A --filter expression (e.g. FullyQualifiedName~Smoke, Category=Integration) does not match any test name/trait, so the runner correctly reports zero matches.

Missing test SDK or adapter package

Discovery needs Microsoft.NET.Test.Sdk plus the framework adapter (xunit.runner.visualstudio or NUnit3TestAdapter). Without them, no discoverer is registered and no tests are found.

How to fix it

Add the test SDK and adapter packages

Reference the SDK and the adapter for your framework in the test project.

Tests.csproj
<!-- Tests.csproj -->
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.*" />
  <PackageReference Include="xunit" Version="2.*" />
  <PackageReference Include="xunit.runner.visualstudio" Version="2.*" />
  <!-- NUnit: NUnit + NUnit3TestAdapter -->
</ItemGroup>

Fix the filter and confirm discovery

  1. List tests with dotnet test --list-tests to see what is actually discovered.
  2. Correct the --filter to match real names/traits (operators: =, !=, ~).
  3. Ensure the test project built for the same target framework the runner uses.

How to prevent it

  • Reference Microsoft.NET.Test.Sdk + the framework adapter in every test project.
  • Validate filters with --list-tests before relying on them in CI.
  • Build and test against the same target framework.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →