The dotnet test command is part of the .NET CLI and is used to run tests in a given solution. It supports multiple test frameworks, including MSTest, xUnit, NUnit and TUnit. The command recognizes two main test platforms: VSTest and Microsoft.Testing.Platform (MTP). Any test framework built on top of either VSTest or MTP is automatically supported. The command builds the solution and executes the tests, providing detailed results and diagnostics.

In this blog post, we’ll explore the significant improvements to dotnet test in .NET 10 through Microsoft.Testing.Platform integration. We will cover:

• Platform comparison: Understanding the differences between VSTest and Microsoft.Testing.Platform (MTP)
• Evolution timeline: How dotnet test integration has progressed from .NET 9 to .NET 10
• Key benefits: Performance improvements, enhanced diagnostics, and new capabilities enabled by MTP
• Enhanced options: New and improved command-line options for flexible test execution
• Practical examples: Real-world usage scenarios and configuration patterns

Whether you’re looking to improve your testing workflow’s performance or access advanced features, this guide will help you leverage the full potential of the new dotnet test experience.

VSTest vs. Microsoft.Testing.Platform (MTP)

Microsoft.Testing.Platform (MTP) is a lightweight and portable alternative to VSTest for running tests in all contexts, including continuous integration (CI) pipelines, CLI, Visual Studio Test Explorer, and VS Code Text Explorer. The Microsoft.Testing.Platform is embedded directly in your test projects, and there’s no other app dependencies.

For the latest updates on Microsoft.Testing.Platform adoption, see our recent post.

To learn more about MTP vs VSTest, see Microsoft.Testing.Platform and VSTest comparison.

Evolution of dotnet test with MTP

The integration of Microsoft.Testing.Platform with dotnet test has undergone significant improvements from .NET 9 to .NET 10. Understanding this evolution helps explain why the current approach delivers better performance and enhanced developer experience.

.NET 9 (Previous Approach)

In .NET 9, Microsoft.Testing.Platform could be used with dotnet test through VSTest mode. This required:

1. Using the -- separator to pass arguments
2. Enabling the TestingPlatformDotnetTestSupport MSBuild property

dotnet test -- --coverage --report-trx

While functional, this approach had several limitations that prompted improvements in .NET 10. For detailed information, see Use Microsoft.Testing.Platform in the VSTest mode of dotnet test.

.NET 10 (Current Approach)

.NET 10 introduces native integration with Microsoft.Testing.Platform. To enable it, create a dotnet.config file at your solution or repository root.

[dotnet.test.runner]
name = "Microsoft.Testing.Platform"

This configuration eliminates the need for complex command-line arguments and provides seamless integration with the .NET SDK.

dotnet test with MTP

Here’s a breakdown of the key benefits of using the Microsoft.Testing.Platform (MTP) with dotnet test over the VSTest integration:

🌐 Unified Test Execution

MTP is designed to be the future of test execution in .NET. It integrates more tightly with the .NET SDK and dotnet test, offering a more consistent experience.

📊 Better Performance

MTP is optimized for performance, especially in large test suites. It reduces start times and improves test discovery and execution speed.

✅ Improved Diagnostics and Logging

MTP provides richer diagnostics, including better structured logs. This makes it easier to troubleshoot flaky tests or performance issues.

▶️ Parallel Test Execution

Execution of assemblies from different TFMs is supported with MTP, which is crucial for scaling test runs in CI pipelines.

📦 Dynamic Arguments

The test-related arguments are no longer fixed, as they are tied to the registered extensions in the test project(s).

⚖️ Globbing Filter

It allows for flexible and efficient test selection by using patterns to include or exclude specific test assemblies, simplifying configuration and improving usability.

✅ Improved UI/UX

The output is nicely formatted with the usage of ANSI terminal.

To learn more about MTP and its foundational principles, see Microsoft.Testing.Platform.

See It in Action

Watch this demonstration of the enhanced dotnet test experience with Microsoft.Testing.Platform (MTP), showcasing how MTP’s native integration delivers performance gains, improved output formatting, and new command-line options in action:

Mixed Project Compatibility

This means you need to migrate all test projects in your solution to MTP before enabling the dotnet.config setting. You cannot run a mixed environment where some projects use VSTest and others use MTP.

Project Properties Cleanup

With native MTP integration in .NET 10, several MSBuild properties from the previous approach are no longer needed and can be safely removed from your test projects:

• TestingPlatformDotnetTestSupport: No longer required for MTP integration
• TestingPlatformShowTestsFailure: Obsolete, as test failures are now displayed by default in the new experience

Options

With Microsoft.Testing.Platform integration, dotnet test provides enhanced flexibility in how you target and execute tests. The following sections cover the various options available to customize your testing workflow, from basic execution to advanced filtering and configuration.

The Default Option

To run the tests in the project or solution in the current directory

dotnet test

Project/Solution Options

With MTP integration, you must use specific options to target projects, solutions, or directories. This change provides more deterministic behavior and clearer command semantics.

To specify the path of the project file to run (folder name or full path). If not specified, it defaults to the current directory.

dotnet test --project ./TestProject/TestProject.csproj

To specify the path of the solution file to run (folder name or full path). If not specified, it defaults to the current directory.

dotnet test --solution ./TestProjects/TestProjects.sln

Globbing Filter Option

The --test-modules option provides powerful globbing pattern support for targeting specific test assemblies. This is particularly useful when you need to run tests from pre-built assemblies or when working with complex solution structures where you want precise control over which test modules execute.

To run tests for specific assemblies

dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"

To run tests for assemblies with a specific root directory

dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"

This approach is ideal for scenarios where you have already compiled test assemblies and want to execute them directly without going through the build process, providing the same flexibility locally that was previously only available through Azure DevOps task.

Max Parallel Test Modules Option

It specifies the maximum number of test modules that can run in parallel.

dotnet test --max-parallel-test-modules 4

Output Options

We use the ANSI terminal, so when running dotnet test, the progress will be displayed as follows

dotnet test

To disable outputting ANSI escape characters to screen.

dotnet test --no-ansi

To disable reporting progress to screen.

dotnet test --no-progress

To specify the output verbosity when reporting tests. Valid values are Normal and Detailed. The default is Normal.

dotnet test --output Detailed

Test Application Arguments

Those extra arguments are passed to the test application(s). Use a space to separate multiple arguments. For more information and examples on what to pass, see Microsoft.Testing.Platform overview and Microsoft.Testing.Platform extensions.

Build and Configuration Options

The following traditional dotnet test options remain available with the new version:

dotnet test [-a|--arch <ARCHITECTURE>]
            [-c|--configuration <CONFIGURATION>]
            [-f|--framework <FRAMEWORK>]
            [--os <OS>]
            [-r|--runtime <RUNTIME_IDENTIFIER>]
            [-v|--verbosity <LEVEL>]
            [--no-build]
            [--no-restore]

These options provide the same build and runtime control as before:

• Architecture: Specify target architecture (-a|--arch)
• Configuration: Set build configuration like Debug or Release (-c|--configuration)
• Framework: Target specific framework version (-f|--framework)
• Operating System: Target specific OS (--os)
• Runtime: Specify runtime identifier (-r|--runtime)
• Verbosity: Control output detail level (-v|--verbosity)
• Build Control: Skip build (--no-build) or restore (--no-restore) steps

MSBuild Properties

MSBuild property support continues to work as before with MTP integration. You can pass one or more MSBuild properties using both short and long forms

# Using short form
dotnet test -p:DefineConstants="DEV"

# Using long form  
dotnet test --property:Configuration=Release

# Multiple properties
dotnet test -p:DefineConstants="DEV" -p:Configuration=Release

The same applies for /property:property=value and its short form is /p.

Wrapping up

The evolution of dotnet test with Microsoft.Testing.Platform represents a significant step forward in .NET testing capabilities. By moving from VSTest integration approach in .NET 9 to the MTP integration in .NET 10, developers now enjoy:

• Simplified configuration through dotnet.config file
• Enhanced performance: more efficient communication between test applications and .NET CLI
• Rich diagnostics with structured logging and ANSI-formatted output
• Flexible test selection using advanced globbing patterns
• Future-ready architecture designed for long-term .NET evolution

Community Feedback

For a detailed documentation on the new dotnet test, see dotnet test.

We encourage you to try out these new capabilities and share your experience with the community. Your feedback helps us continue improving the .NET testing ecosystem. Please share your thoughts, report issues, or start discussions on the .NET SDK repository.