From dotnet-test
Migrates .NET test projects from xUnit.net v2 to v3: updates package references, verifies compatibility (.NET 8+, SDK-style), baselines tests with dotnet test, ensures clean builds and passing tests.
npx claudepluginhub dotnet/skills --plugin dotnet-testThis skill uses the workspace's default tool permissions.
Migrate .NET test projects from xUnit.net v2 to xUnit.net v3. The outcome is a solution where all test projects reference `xunit.v3.*` packages, compiles cleanly, and all tests pass with the same results as before migration.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Migrate .NET test projects from xUnit.net v2 to xUnit.net v3. The outcome is a solution where all test projects reference xunit.v3.* packages, compiles cleanly, and all tests pass with the same results as before migration.
xunit (v2) packages to xunit.v3migrate-vstest-to-mtpxunit.v3 — migration is done| Input | Required | Description |
|---|---|---|
| Test project or solution | Yes | The .NET project or solution containing xUnit.net v2 test projects |
Commit strategy: Commit after each major step so the migration is reviewable and bisectable. Separate project file changes from code changes.
Search for test projects referencing xUnit.net v2 packages:
xunitxunit.abstractionsxunit.assertxunit.corexunit.extensibility.corexunit.extensibility.executionxunit.runner.visualstudioMake sure to check the package references in project files, MSBuild props and targets files, like Directory.Build.props, Directory.Build.targets, and Directory.Packages.props.
Run dotnet test to establish a baseline of test pass/fail counts. When running dotnet test, ensure that:
dotnet test without any additional arguments (i.e., don't pass --no-restore or --no-build).Update any PackageReference or PackageVersion items for the new package names, based on the following mapping:
xunit → xunit.v3xunit.abstractions → Remove entirelyxunit.assert → xunit.v3.assertxunit.core → xunit.v3.corexunit.extensibility.core and xunit.extensibility.execution → xunit.v3.extensibility.core (if both are referenced in a project consolidate to only a single entry as the two packages are merged)Update all xunit.v3.* packages to the latest correct version available on NuGet. Also update xunit.runner.visualstudio to the latest version.
OutputType to ExeIn each test project (excluding test library projects), set OutputType to Exe in the project file:
<PropertyGroup>
<OutputType>Exe</OutputType>
</PropertyGroup>
Depending on the solution in hand, there might be a centralized place where this can be added. For example:
Directory.Build.props, add the <OutputType>Exe</OutputType> property there. Note that the OutputType should not be added to Directory.Build.targets.*.Tests.csproj), add a conditional property group in Directory.Build.props that applies only to those projects, like <OutputType Condition="$(MSBuildProjectName.EndsWith('.Tests'))">Exe</OutputType>. Adjust the condition as needed to target only test projects.<OutputType>Exe</OutputType> property to each test project file individually.Xunit.Abstractions usingsFind any using Xunit.Abstractions; directives in C# files and remove them completely.
async void breaking changeIn xUnit.net v3, async void test methods are no longer supported and will fail to compile. Search for any test methods declared with async void and change them to async Task. Test methods can be identified via the [Fact] or [Theory] attributes or other test attributes.
In xUnit.net v3, some attributes were updated so that they accept a System.Type instead of two strings (fully qualified type name and assembly name). These attributes are:
CollectionBehaviorAttributeTestCaseOrdererAttributeTestCollectionOrdererAttributeTestFrameworkAttributeFor example, [assembly: CollectionBehavior("MyNamespace.MyCollectionFactory", "MyAssembly")] must be converted to [assembly: CollectionBehavior(typeof(MyNamespace.MyCollectionFactory))].
Identify if there are any custom attributes that inherit from FactAttribute or TheoryAttribute. These custom user-defined attributes must now provide source information. For example, if the attribute looked like this:
internal sealed class MyFactAttribute : FactAttribute
{
public MyFactAttribute()
{
}
}
it must be changed to this:
internal sealed class MyFactAttribute : FactAttribute
{
public MyFactAttribute(
[CallerFilePath] string? sourceFilePath = null,
[CallerLineNumber] int sourceLineNumber = -1
) : base(sourceFilePath, sourceLineNumber)
{
}
}
Identify if there are any custom attributes that inherit from BeforeAfterTestAttribute. These custom user-defined attributes must update their method signatures. Previously, they would have Before/After overrides that look like this:
public override void Before(MethodInfo methodUnderTest)
{
// Possibly some custom logic here
base.Before(methodUnderTest);
// Possibly some custom logic here
}
public override void After(MethodInfo methodUnderTest)
{
// Possibly some custom logic here
base.After(methodUnderTest);
// Possibly some custom logic here
}
it must be changed to this:
public override void Before(MethodInfo methodUnderTest, IXunitTest test)
{
// Possibly some custom logic here
base.Before(methodUnderTest, test);
// Possibly some custom logic here
}
public override void After(MethodInfo methodUnderTest, IXunitTest test)
{
// Possibly some custom logic here
base.After(methodUnderTest, test);
// Possibly some custom logic here
}
xunit.v3 introduced new analyzer warnings. You should attempt to address them.
One of the most notable warnings is xUnit1051: Calls to methods which accept CancellationToken should use TestContext.Current.CancellationToken. Identify the calls to such methods, if any, and pass the cancellation token.
You should keep the same test platform that was used with xunit 2.
Note that xunit 2 is always VSTest except if the user used YTest.MTP.XUnit2.
<UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> to Directory.Build.props under an unconditional PropertyGroup.<IsTestingPlatformApplication>false</IsTestingPlatformApplication> to Directory.Build.props under an unconditional PropertyGroup.Xunit.SkippableFactIf there are any package references to Xunit.SkippableFact, remove all these package references entirely.
Then, follow these steps to eliminate usages of APIs coming from the removed package reference:
SkippableFact attribute to the regular Fact attribute.SkippableTheory attribute to the regular Theory attribute.Skip.If method calls to Assert.SkipWhen.Skip.IfNot method calls to Assert.SkipUnless.Xunit.Combinatorial NuGet packageFind package references of Xunit.Combinatorial and update them from 1.x to the latest 2.x version available.
Xunit.StaFact NuGet packageFind package references of Xunit.StaFact and update them from 1.x to the latest 3.x version available.
Now, build the solution to identify any remaining compilation errors that might not have been addressed by previous instructions. Fix any straightforward errors that show up, and keep iterating and fixing more.
You can also look into https://xunit.net/docs/getting-started/v3/migration-extensibility and https://xunit.net/docs/getting-started/v3/migration to help with the remaining compilation errors.
You can fix as much as you can, and it's okay if not everything is fixed. Just tell the user that there are remaining errors that need to be manually addressed.