Sign up to save your podcasts
Or
Share Enhance your CLI testing workflow with the new dotnet test
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Enhance your CLI testing workflow with the new dotnet test
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:
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:
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.
Configuration Scope
The dotnet.config file must be placed at the solution or repository level. Global configuration at the user or machine level is currently not supported.[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.
Migration Path
The new approach simplifies test execution while providing better performance and diagnostics compared to the VSTest integration method.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
All-or-Nothing Requirement
In a solution with MTP enabled via dotnet.config, every test project must use Microsoft.Testing.Platform. Having any VSTest projects will prevent those projects from being able to run.
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:
Clean Up Tip
Remove these properties during migration to simplify your project files and avoid confusion with old configuration options.
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
Breaking Change
The traditional syntax dotnet test \ (e.g., dotnet test MyProject.csproj, dotnet test MySolution.sln, or dotnet test MyFolder) is no longer supported.
You must now use explicit options to specify your target.
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.
Mutually Exclusive Options
These target selection options are mutually exclusive – use only one at a time:–project, –solution, or –test-modules.
When using –test-modules, build options (like –configuration or –framework) are not available since they don’t apply to pre-built assemblies.
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
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test.mp4
To disable outputting ANSI escape characters to screen.
dotnet test --no-ansi
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test-no-ansi.mp4
To disable reporting progress to screen.
dotnet test --no-progress
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test-no-progress.mp4
To specify the output verbosity when reporting tests. Valid values are Normal and Detailed. The default is Normal.
dotnet test --output Detailed
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test-output-detailed.mp4
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 ]
[-c|--configuration ]
[-f|--framework ]
[--os ]
[-r|--runtime ]
[-v|--verbosity ]
[--no-build]
[--no-restore]
These options provide the same build and runtime control as before:
Incompatible Solution Options
Running tests for a solution with a global RuntimeIdentifier property (explicitly or via --arch, --runtime, or --os) is not supported. You can set RuntimeIdentifier on individual project level instead.
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:
Get Started Today
Ready to upgrade? Start by converting a single test project to MTP, then gradually migrate your entire solution. The improved performance and diagnostics will immediately enhance your development workflow.
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.
The post Enhance your CLI testing workflow with the new dotnet test appeared first on .NET Blog.
View all episodes
By 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:
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:
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.
Configuration Scope
The dotnet.config file must be placed at the solution or repository level. Global configuration at the user or machine level is currently not supported.[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.
Migration Path
The new approach simplifies test execution while providing better performance and diagnostics compared to the VSTest integration method.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
All-or-Nothing Requirement
In a solution with MTP enabled via dotnet.config, every test project must use Microsoft.Testing.Platform. Having any VSTest projects will prevent those projects from being able to run.
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:
Clean Up Tip
Remove these properties during migration to simplify your project files and avoid confusion with old configuration options.
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
Breaking Change
The traditional syntax dotnet test \ (e.g., dotnet test MyProject.csproj, dotnet test MySolution.sln, or dotnet test MyFolder) is no longer supported.
You must now use explicit options to specify your target.
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.
Mutually Exclusive Options
These target selection options are mutually exclusive – use only one at a time:–project, –solution, or –test-modules.
When using –test-modules, build options (like –configuration or –framework) are not available since they don’t apply to pre-built assemblies.
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
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test.mp4
To disable outputting ANSI escape characters to screen.
dotnet test --no-ansi
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test-no-ansi.mp4
To disable reporting progress to screen.
dotnet test --no-progress
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test-no-progress.mp4
To specify the output verbosity when reporting tests. Valid values are Normal and Detailed. The default is Normal.
dotnet test --output Detailed
https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2025/08/dotnet-test-output-detailed.mp4
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 ]
[-c|--configuration ]
[-f|--framework ]
[--os ]
[-r|--runtime ]
[-v|--verbosity ]
[--no-build]
[--no-restore]
These options provide the same build and runtime control as before:
Incompatible Solution Options
Running tests for a solution with a global RuntimeIdentifier property (explicitly or via --arch, --runtime, or --os) is not supported. You can set RuntimeIdentifier on individual project level instead.
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:
Get Started Today
Ready to upgrade? Start by converting a single test project to MTP, then gradually migrate your entire solution. The improved performance and diagnostics will immediately enhance your development workflow.
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.
The post Enhance your CLI testing workflow with the new dotnet test appeared first on .NET Blog.