{"id":2403,"date":"2025-08-21T17:33:47","date_gmt":"2025-08-21T17:33:47","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/08\/21\/enhance-your-cli-testing-workflow-with-the-new-dotnet-test\/"},"modified":"2025-08-21T17:33:47","modified_gmt":"2025-08-21T17:33:47","slug":"enhance-your-cli-testing-workflow-with-the-new-dotnet-test","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/08\/21\/enhance-your-cli-testing-workflow-with-the-new-dotnet-test\/","title":{"rendered":"Enhance your CLI testing workflow with the new dotnet test"},"content":{"rendered":"

The dotnet test<\/a> 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.<\/p>\n

In this blog post, we\u2019ll explore the significant improvements to dotnet test in .NET 10 through Microsoft.Testing.Platform integration. We will cover:<\/p>\n

Platform comparison<\/strong>: Understanding the differences between VSTest and Microsoft.Testing.Platform (MTP)
\nEvolution timeline<\/strong>: How dotnet test integration has progressed from .NET 9 to .NET 10
\nKey benefits<\/strong>: Performance improvements, enhanced diagnostics, and new capabilities enabled by MTP
\nEnhanced options<\/strong>: New and improved command-line options for flexible test execution
\nPractical examples<\/strong>: Real-world usage scenarios and configuration patterns<\/p>\n

Whether you\u2019re looking to improve your testing workflow\u2019s performance or access advanced features, this guide will help you leverage the full potential of the new dotnet test experience.<\/p>\n

VSTest vs. Microsoft.Testing.Platform (MTP)<\/h2>\n

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\u2019s no other app dependencies.<\/p>\n

For the latest updates on Microsoft.Testing.Platform adoption, see our recent post<\/a>.<\/p>\n

To learn more about MTP vs VSTest, see Microsoft.Testing.Platform and VSTest comparison<\/a>.<\/p>\n

Evolution of dotnet test with MTP<\/h2>\n

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.<\/p>\n

.NET 9 (Previous Approach)<\/h3>\n

In .NET 9, Microsoft.Testing.Platform could be used with dotnet test through VSTest mode. This required:<\/p>\n

Using the — separator to pass arguments
\nEnabling the TestingPlatformDotnetTestSupport MSBuild property<\/p>\n

dotnet test — –coverage –report-trx<\/p>\n

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<\/a>.<\/p>\n

.NET 10 (Current Approach)<\/h3>\n

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

\n

Configuration Scope<\/strong><\/p>\n

The dotnet.config<\/strong> file must be placed at the solution or repository level. Global configuration at the user or machine level is currently not supported.<\/p><\/div>\n

[dotnet.test.runner]
\nname = “Microsoft.Testing.Platform”<\/p>\n

This configuration eliminates the need for complex command-line arguments and provides seamless integration with the .NET SDK.<\/p>\n\n

\n

Migration Path<\/strong><\/p>\n

The new approach simplifies test execution while providing better performance and diagnostics compared to the VSTest integration method.<\/p><\/div>\n

dotnet test with MTP<\/h2>\n

Here\u2019s a breakdown of the key benefits of using the Microsoft.Testing.Platform (MTP)\u00a0with\u00a0dotnet test over the VSTest\u00a0integration:<\/p>\n

Unified Test Execution<\/p>\n

MTP\u00a0is designed to be the future of test execution in .NET. It integrates more tightly with the .NET SDK and\u00a0dotnet test, offering a more consistent experience.<\/p>\n

Better Performance<\/p>\n

MTP is optimized for performance, especially in large test suites. It reduces start times and improves test discovery and execution speed.<\/p>\n

Improved Diagnostics and Logging<\/p>\n

MTP provides\u00a0richer diagnostics, including better structured logs. This makes it easier to troubleshoot flaky tests or performance issues.<\/p>\n

Parallel Test Execution<\/p>\n

Execution of assemblies from different TFMs is supported with MTP, which is crucial for scaling test runs in CI pipelines.<\/p>\n

Dynamic Arguments<\/p>\n

The test-related arguments are no longer fixed, as they are tied to the registered extensions in the test project(s).<\/p>\n

\u00a0Globbing Filter<\/p>\n

It allows for flexible and efficient test selection by using patterns to include or exclude specific test assemblies, simplifying configuration and improving usability.<\/p>\n

Improved UI\/UX<\/p>\n

The output is nicely formatted with the usage of ANSI terminal.<\/p>\n

To learn more about MTP and its foundational principles, see Microsoft.Testing.Platform<\/a>.<\/p>\n

See It in Action<\/h3>\n

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

Mixed Project Compatibility<\/h2>\n\n
\n

All-or-Nothing Requirement<\/strong><\/p>\n

In a solution with MTP enabled via dotnet.config<\/strong>, every test project must use Microsoft.Testing.Platform. Having any VSTest projects will prevent those projects from being able to run.\n<\/p><\/div>\n

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.<\/p>\n

Project Properties Cleanup<\/h2>\n

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:<\/p>\n

TestingPlatformDotnetTestSupport<\/strong>: No longer required for MTP integration
\nTestingPlatformShowTestsFailure<\/strong>: Obsolete, as test failures are now displayed by default in the new experience<\/p>\n

\n

Clean Up Tip<\/strong><\/p>\n

Remove these properties during migration to simplify your project files and avoid confusion with old configuration options.\n<\/p><\/div>\n

Options<\/h2>\n

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.<\/p>\n

The Default Option<\/h3>\n

To run the tests in the project or solution in the current directory<\/p>\n

dotnet test<\/p>\n

Project\/Solution Options<\/h3>\n\n
\n

Breaking Change<\/strong><\/p>\n

The traditional syntax dotnet test <path><\/strong> (e.g., dotnet test MyProject.csproj<\/strong>, dotnet test MySolution.sln<\/strong>, or dotnet test MyFolder<\/strong>) is no longer supported.
\nYou must now use explicit options to specify your target.\n<\/p><\/div>\n

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

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

dotnet test –project .\/TestProject\/TestProject.csproj<\/p>\n

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

dotnet test –solution .\/TestProjects\/TestProjects.sln<\/p>\n

Globbing Filter Option<\/h3>\n

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.<\/p>\n

To run tests for specific assemblies<\/p>\n

dotnet test –test-modules “**\/bin\/**\/Debug\/net10.0\/TestProject.dll”<\/p>\n

To run tests for assemblies with a specific root directory<\/p>\n

dotnet test –test-modules “**\/bin\/**\/Debug\/net10.0\/TestProject.dll” –root-directory “c:code”<\/p>\n

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.<\/p>\n\n

\n

Mutually Exclusive Options<\/strong><\/p>\n

These target selection options are mutually exclusive \u2013 use only one at a time:\u2013project<\/strong>, \u2013solution<\/strong>, or \u2013test-modules<\/strong>.<\/p>\n

When using \u2013test-modules<\/strong>, build options (like \u2013configuration<\/strong> or \u2013framework<\/strong>) are not available since they don\u2019t apply to pre-built assemblies.\n<\/p>\n<\/div>\n

Max Parallel Test Modules Option<\/h3>\n

It specifies the maximum number of test modules that can run in parallel.<\/p>\n

dotnet test –max-parallel-test-modules 4<\/p>\n

Output Options<\/h3>\n

We use the ANSI terminal, so when running dotnet test, the progress will be displayed as follows<\/p>\n

dotnet test<\/p>\n


\nhttps:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/08\/dotnet-test.mp4<\/a><\/div>\n

To disable outputting ANSI escape characters to screen.<\/p>\n

dotnet test –no-ansi<\/p>\n

https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/08\/dotnet-test-no-ansi.mp4<\/a><\/div>\n

To disable reporting progress to screen.<\/p>\n

dotnet test –no-progress<\/p>\n

https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/08\/dotnet-test-no-progress.mp4<\/a><\/div>\n

To specify the output verbosity when reporting tests. Valid values are Normal and Detailed. The default is Normal.<\/p>\n

dotnet test –output Detailed<\/p>\n

https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2025\/08\/dotnet-test-output-detailed.mp4<\/a><\/div>\n

Test Application Arguments<\/h3>\n

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<\/a> overview and Microsoft.Testing.Platform<\/a> extensions.<\/p>\n

Build and Configuration Options<\/h3>\n

The following traditional dotnet test options remain available with the new version:<\/p>\n

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

These options provide the same build and runtime control as before:<\/p>\n

Architecture<\/strong>: Specify target architecture (-a|–arch)
\nConfiguration<\/strong>: Set build configuration like Debug or Release (-c|–configuration)
\nFramework<\/strong>: Target specific framework version (-f|–framework)
\nOperating System<\/strong>: Target specific OS (–os)
\nRuntime<\/strong>: Specify runtime identifier (-r|–runtime)
\nVerbosity<\/strong>: Control output detail level (-v|–verbosity)
\nBuild Control<\/strong>: Skip build (–no-build) or restore (–no-restore) steps<\/p>\n

MSBuild Properties<\/h3>\n

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<\/p>\n

# Using short form
\ndotnet test -p:DefineConstants=”DEV”<\/p>\n

# Using long form
\ndotnet test –property:Configuration=Release<\/p>\n

# Multiple properties
\ndotnet test -p:DefineConstants=”DEV” -p:Configuration=Release<\/p>\n

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

Wrapping up<\/h2>\n

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:<\/p>\n

Simplified configuration<\/strong> through dotnet.config file
\nEnhanced performance<\/strong>: more efficient communication between test applications and .NET CLI
\nRich diagnostics<\/strong> with structured logging and ANSI-formatted output
\nFlexible test selection<\/strong> using advanced globbing patterns
\nFuture-ready architecture<\/strong> designed for long-term .NET evolution<\/p>\n

\n

Get Started Today<\/strong><\/p>\n

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.\n<\/p><\/div>\n

Community Feedback<\/h2>\n

For a detailed documentation on the new dotnet test, see dotnet test<\/a>.<\/p>\n

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<\/a>.<\/p>\n

The post Enhance your CLI testing workflow with the new dotnet test<\/a> appeared first on .NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

The dotnet test command is part of the .NET CLI and is used to run tests in a given solution. […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-2403","post","type-post","status-publish","format-standard","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/2403","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=2403"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/2403\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=2403"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=2403"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=2403"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}