xUnit.net

Trigger On

• the repo uses xUnit v2 or xUnit v3
• you need to add, run, debug, or repair xUnit tests
• the team is unsure whether a project is using VSTest or Microsoft.Testing.Platform

Workflow

1. Detect the active xUnit model before changing commands:

- xunit usually means v2 - xunit.v3 means v3 - xunit.runner.visualstudio plus Microsoft.NET.Test.Sdk usually means VSTest compatibility is enabled - TestingPlatformDotnetTestSupport or UseMicrosoftTestingPlatformRunner means Microsoft.Testing.Platform is in play

1. Read the repo's real test command from AGENTS.md. If the repo has no explicit command yet, start with dotnet test PROJECT_OR_SOLUTION.
2. Keep the runner model consistent:

- xUnit v2 usually runs through VSTest - xUnit v3 can run as a standalone executable with dotnet run - xUnit v3 can also integrate with Microsoft.Testing.Platform - do not mix VSTest-only switches into Microsoft.Testing.Platform runs

1. Run the narrowest useful scope first:

- one project - one class - one trait - one method

1. Prefer [Theory] for stable data-driven coverage and [Fact] for single-path invariant checks.
2. Keep xunit.analyzers enabled when present. Fix analyzer findings instead of muting them casually.

Deliver

• xUnit tests that match the repo's active xUnit version and runner
• commands that work in local and CI runs
• focused verification before broader suite execution

Validate

• the chosen CLI matches the active runner model
• test filters or focused runs are valid for that runner
• tests use deterministic inputs and assertions
• xUnit-specific analyzers remain active unless the repo documents an exception

Load References

Related skills