xunit

Run `dotnet test` on the solution or test project for VSTest-based setups, which covers most xUnit v2 projects. For xUnit v3 standalone projects, use `dotnet run --project` on the test project instead, since v3 can execute as its own executable.

xUnit v2 uses the `xunit` package and typically runs through VSTest with `xunit.runner.visualstudio`. xUnit v3 uses the `xunit.v3` package and can run as a standalone executable or integrate with Microsoft.Testing.Platform, changing which CLI commands and filters apply.

Check the project file first: `xunit.runner.visualstudio` with `Microsoft.NET.Test.Sdk` indicates VSTest, while `TestingPlatformDotnetTestSupport` or `UseMicrosoftTestingPlatformRunner` indicates Microsoft.Testing.Platform. Keep one runner model per project and never mix VSTest-only flags with platform flags in the same command.

For VSTest runs, use `dotnet test --filter "FullyQualifiedName~Namespace.TypeName"`. For xUnit v3 with Microsoft.Testing.Platform, use `dotnet run --project ... -- --filter-class Namespace.TypeName`. Always match the filter syntax to the active runner.

Do not use it for TUnit or MSTest projects, since their packages, runners, and idioms differ. It also does not auto-migrate repos from other frameworks to xUnit unless migration is explicitly requested.

Intermittent failures usually come from shared mutable state between tests, reliance on wall-clock time or randomness, or `async void` test methods that xUnit cannot await. Use per-test setup, inject time providers, and return `Task` from async tests to make them deterministic.