What's New in .NET 10 Testing: Microsoft.Testing.Platform, dotnet test Changes, and What Enterprise Teams Should Adopt in 2026

The .NET 10 testing story is one of the most consequential changes in this LTS cycle — and it is not getting enough attention. The dotnet 10 Microsoft.Testing.Platform shift replaces VSTest as the default test runner, rewires how dotnet test works, and changes what teams need in their CI pipelines. If your enterprise has 20 test projects, a custom Azure DevOps pipeline, and a mix of xUnit, NUnit, and MSTest — this affects you. Here is a clear breakdown of what changed, what it means, and which parts to adopt right now.

🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 https://www.patreon.com/CodingDroplets

Why .NET 10 Changed the Testing Architecture

For years, VSTest was the backbone of .NET testing. It worked, but it came with real costs: process isolation via vstest.console.exe, dependency on host-side plugin resolution, inconsistent behavior between local runs and CI, and limited extensibility for modern test scenarios.

Microsoft.Testing.Platform (MTP) is the architectural answer. Instead of an external process orchestrating your tests, MTP is embedded directly inside the test project itself. When you run a test project built on MTP, it is a self-contained executable — no vstest.console, no external coordinator. The determinism and runtime transparency this enables are not just marketing claims; they eliminate a whole category of "works locally, fails in CI" bugs.

Starting with the .NET 10 SDK, MTP is the default for dotnet test. Teams that have already opted in on .NET 8 or .NET 9 will feel continuity. Teams still on VSTest workflows will need a migration plan.

What Is Microsoft.Testing.Platform and How Is It Different?

Microsoft.Testing.Platform is an open-source, lightweight test runner that embeds directly into test assemblies. The key architectural differences from VSTest are:

Determinism by design. MTP does not use reflection, AppDomain, or AssemblyLoadContext to orchestrate runs. The same test run produces the same result on your laptop and in the GitHub Actions runner — no more environment-dependent surprises.

No external coordinator. With VSTest, running tests required vstest.console.exe or the dotnet test adapter layer to spin up a host process. With MTP, the test binary is self-hosting. You can execute tests directly, without the .NET SDK installed on the target machine, if the project is published as self-contained.

Extensibility without hacks. VSTest plugins were fragile — they relied on assembly scanning at the runner level. MTP exposes first-class extension points: test discovery, test execution, diagnostics, and reporting are all composable via explicit APIs.

Framework parity. As of 2026, all three major frameworks — xUnit, NUnit, and MSTest — have shipped MTP runners. TUnit was built on MTP from day one. The migration path now exists for virtually every enterprise project.

What Changed in dotnet test for .NET 10 SDK?

The dotnet test command in .NET 10 SDK has undergone a meaningful rewrite, not just a flag change.

MTP is the default. On .NET 10 SDK, projects using MTP-compatible framework runners no longer need TestingPlatformDotnetTestSupport=true. It is on by default.

VSTest fallback still exists, for now. If your project targets .NET 8 or .NET 9 (even when built with the .NET 10 SDK), VSTest mode is preserved via compatibility shims. The MTP v2 drop makes this clear: attempting to run VSTest-mode MTP on .NET 10 SDK will produce an error and you must opt into the new dotnet test experience.

Azure DevOps pipeline impact. The VSTest task in Azure DevOps pipelines needs attention. Microsoft recommends replacing it with the DotNetCoreCLI task for projects migrating to MTP. Teams using DotNetCoreCLI without explicitly opting in via global.json or project-level settings need to verify the results directory path and TRX report parameters.

--cli-schema for introspection. A new --cli-schema flag on all CLI commands outputs a JSON description of the command tree. For teams managing complex pipeline scripts or building internal tooling, this enables self-documenting CLI workflows.

dotnet tool exec for one-shot tools. CI pipelines that previously relied on globally installed tools gain a cleaner alternative: dotnet tool exec runs a NuGet-sourced tool once without installing it. This reduces pipeline setup time and eliminates version drift between CI agents.

Which Framework Should Your Enterprise Team Use With MTP?

The choice of test framework under MTP is now a first-class decision for .NET 10 teams.

MSTest with MTP runner is the lowest-friction path for shops already on MSTest. The MSTest runner (MSTest.Runner) ships as part of the MSTest NuGet packages and plugs into MTP. Enterprise teams with large legacy MSTest suites should evaluate this path first — it requires minimal test code changes.

xUnit with MTP adapter is well-supported. The xunit.runner.mtp package provides native MTP integration. xUnit is the most popular choice for greenfield .NET projects and continues to be the framework of record for most open-source .NET libraries.

NUnit with MTP runner is production-ready as of the 2026 releases. NUnit's runner package integrates via MTP's extension model and retains compatibility with existing [TestFixture] and [Test] attributes.

TUnit is purpose-built for MTP and represents where .NET testing is heading. It supports source generators for test discovery (eliminating reflection), ships with dependency injection baked in, and is the only framework that does not support VSTest at all. For teams starting fresh on .NET 10, TUnit is worth serious evaluation.

Is This the Right Time to Migrate? A Decision Framework

Not every team should migrate on day one of .NET 10 adoption. Use this framework:

Migrate now if:

• You are starting a new service or project on .NET 10 from scratch
• Your CI already uses dotnet test with the DotNetCoreCLI task (low migration cost)
• You are experiencing VSTest flakiness in CI (MTP's determinism directly addresses this)
• You want to use TUnit or any MTP-native extension

Wait and validate if:

• You have custom VSTest adapter plugins that do not have MTP equivalents yet
• You are in a regulated environment where toolchain changes require formal validation cycles
• Your Azure DevOps pipeline uses the legacy VSTest task with custom test settings files
• You depend on third-party test result processors or quality gates built around VSTest's .trx format

Do not delay if:

• You are planning to upgrade to .NET 10 SDK in CI — test that MTP works in your pipeline before upgrading, not after

What to Adopt Now vs. Later

Adopt Now

• Upgrade to MTP runner for your framework if you are on .NET 10 SDK
• Replace the Azure DevOps VSTest task with DotNetCoreCLI in new pipelines
• Enable TestingPlatformDotnetTestSupport=true for existing .NET 9 projects as a rehearsal step
• Evaluate TUnit for any new test project in the solution

Adopt Later (After Validation)

• Full VSTest-to-MTP migration for large legacy suites — do this incrementally, project by project
• MTP extension development if you have internal test infrastructure tooling
• TUnit for existing codebases — the rewrite cost is real; plan it as a project, not a sprint task

Keep Watching

• dnx script — early adopters report friction in some CI environments; wait for stable toolchain support
• MTP v2 hot reload integration — Visual Studio 2026 is expanding hot-reload hooks into test runs; currently in preview

What Does This Mean for Enterprise CI/CD Pipelines?

Enterprise test pipelines need three changes to be .NET 10-ready:

1. Audit your test task configuration. Any pipeline using the VSTest task directly needs to be assessed. If the test projects are migrating to MTP, the VSTest task will not discover them correctly.

2. Validate TRX report generation. MTP generates TRX reports, but the path convention differs from VSTest defaults in some configurations. Update result-collection steps in Azure DevOps or GitHub Actions to use --results-directory explicitly.

3. Standardize on dotnet tool exec for ephemeral tools. Replace globally installed tools in CI agents with dotnet tool exec calls. This eliminates agent configuration drift and aligns with the .NET 10 SDK design intent.

For teams using GitHub Actions, the actions/setup-dotnet action already supports .NET 10 and MTP integration transparently. No special configuration is required.

For internally hosted build agents, validate that the agents have the .NET 10 SDK installed and that any custom test wrappers account for the new test executable model.

What Is Not Changing (and Why That Matters)

It is worth being clear about what is not changing in .NET 10 testing to avoid unnecessary migration anxiety.

Your test code does not change. Attributes like [Fact], [Theory], [Test], [TestFixture] are framework-level — they are unaffected by the runner underneath. Migrating from VSTest to MTP is a project file and pipeline change, not a test rewrite.

Code coverage still works. Coverlet and other coverage tools have shipped MTP-compatible versions. The --coverage flag in dotnet test integrates with MTP natively in .NET 10.

Test Explorer in Visual Studio 2026 supports both. The IDE maintains backward compatibility. Teams that want to migrate CI first and local tooling second can do so without disrupting developer workflows.

How Does This Relate to the What's New in ASP.NET Core 10 Changes?

The testing improvements in .NET 10 are part of a broader platform maturity story. The What's New in ASP.NET Core 10 post covers how the application layer changes complement these testing upgrades — particularly around integration testing with MTP's self-hosted model and testability improvements in minimal APIs.

For integration testing specifically, the combination of MTP, WebApplicationFactory, and TUnit's DI-native design opens the door to significantly cleaner integration test setups in .NET 10.

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

Frequently Asked Questions

Is VSTest still supported in .NET 10? Yes, VSTest still works in .NET 10, especially for projects targeting .NET 8 or .NET 9 via the .NET 10 SDK. However, VSTest is no longer the default and is not receiving new features. Microsoft's direction is clear: new investment is in Microsoft.Testing.Platform. Teams should treat .NET 10 as the point at which to begin their migration planning.

Does migrating to Microsoft.Testing.Platform require rewriting tests? No. Migrating to MTP is a project configuration and pipeline change, not a test code change. Your existing [Fact], [Test], and [TestFixture] attributes remain unchanged. The migration updates which runner package you reference and how dotnet test invokes the tests.

Which test framework is recommended for new .NET 10 projects? For greenfield .NET 10 projects, TUnit offers the most modern experience — source-generator-based discovery, native DI support, and MTP-first design. For teams on existing xUnit or NUnit codebases, stay with your current framework and adopt the MTP runner package. Switching frameworks for its own sake is rarely worth the cost.

What happens to Azure DevOps pipelines that use the VSTest task? If test projects migrate to MTP, the legacy VSTest task in Azure DevOps will not discover tests correctly. Replace it with the DotNetCoreCLI task. If you are not migrating yet, the VSTest task still functions for projects in VSTest mode. Test your pipeline configuration before upgrading the SDK.

Is dotnet tool exec stable enough for production CI pipelines? For most use cases, yes. dotnet tool exec is GA in .NET 10 and is the recommended way to run ephemeral CLI tools in CI without maintaining global installs. The main caveat is that it performs a NuGet download on first run — ensure your CI environment has NuGet feed access and consider caching the package download directory.

Does Microsoft.Testing.Platform work with code coverage tools like Coverlet? Yes. Coverlet ships MTP-compatible versions and integrates natively with MTP's extension model. The --coverage flag in dotnet test on .NET 10 SDK uses Coverlet under the hood. Teams using custom coverage collection scripts should verify they are referencing the MTP-compatible Coverlet package version.

Can I use MTP with projects still targeting .NET 8 or .NET 9? Yes, MTP is not locked to .NET 10 target frameworks. You can use the MTP runner packages on projects targeting .NET 8 or .NET 9 and built with the .NET 10 SDK. The key constraint is MTP v2: it drops VSTest mode entirely for .NET 10 SDK builds. Projects still in VSTest mode with MTP v2 need to migrate to the new dotnet test experience before upgrading the SDK.