Edit

Share via

dotnet test with Microsoft.Testing.Platform (MTP)

This article applies to: ✔️ .NET 10 SDK and later versions

Name

dotnet test - .NET test driver used to execute unit tests with Microsoft.Testing.Platform.

Synopsis

dotnet test
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>] 
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-restore]
    [--no-ansi]
    [--no-progress]
    [--output <VERBOSITY_LEVEL>]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [<args>...]

dotnet test -h|--help

Description

With Microsoft Testing Platform, dotnet test operates faster than with VSTest. The test-related arguments are no longer fixed, as they are tied to the registered extensions in the test project(s). Moreover, MTP supports a globbing filter when running tests. For more information, see Microsoft.Testing.Platform.

Warning

When Microsoft.Testing.Platform is opted in via global.json, dotnet test expects all test projects to use Microsoft.Testing.Platform. It is an error if any of the test projects use VSTest.

Implicit restore

You don't have to run dotnet restore because it's run implicitly by all commands that require a restore to occur, such as dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish, and dotnet pack. To disable implicit restore, use the --no-restore option.

The dotnet restore command is still useful in certain scenarios where explicitly restoring makes sense, such as continuous integration builds in Azure DevOps Services or in build systems that need to explicitly control when the restore occurs.

For information about how to manage NuGet feeds, see the dotnet restore documentation.

Options

Note

You can use only one of the following options at a time: --project, --solution, or --test-modules. These options can't be combined. In addition, when using --test-modules, you can't specify --arch, --configuration, --framework, --os, or --runtime. These options aren't relevant for an already-built module.

  • --project <PROJECT_PATH>

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

  • --solution <SOLUTION_PATH>

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

  • --test-modules <EXPRESSION>

    Filters test modules using file globbing in .NET. Only tests belonging to those test modules will run. For more information and examples on how to use file globbing in .NET, see File globbing.

  • --root-directory <ROOT_PATH>

    Specifies the root directory of the --test-modules option. It can only be used with the --test-modules option.

  • --max-parallel-test-modules <NUMBER>

    Specifies the maximum number of test modules that can run in parallel. The default is Environment.ProcessorCount.

  • -a|--arch <ARCHITECTURE>

    Specifies the target architecture. This is a shorthand syntax for setting the Runtime Identifier (RID), where the provided value is combined with the default RID. For example, on a win-x64 machine, specifying --arch x86 sets the RID to win-x86. If you use this option, don't use the -r|--runtime option. Available since .NET 6 Preview 7.

  • -c|--configuration <CONFIGURATION>

    Defines the build configuration. The default for most projects is Debug, but you can override the build configuration settings in your project.

  • -f|--framework <FRAMEWORK>

    The target framework moniker (TFM) of the target framework to run tests for. The target framework must also be specified in the project file.

  • --os <OS>

    Specifies the target operating system (OS). This is a shorthand syntax for setting the Runtime Identifier (RID), where the provided value is combined with the default RID. For example, on a win-x64 machine, specifying --os linux sets the RID to linux-x64. If you use this option, don't use the -r|--runtime option. Available since .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    The target runtime to test for.

    Short form -r available starting in .NET SDK 7.

    Note

    Running tests for a solution with a global RuntimeIdentifier property (explicitly or via --arch, --runtime, or --os) isn't supported. Set RuntimeIdentifier on an individual project level instead.

  • -v|--verbosity <LEVEL>

    Sets the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. For more information, see LoggerVerbosity.

  • --no-build

    Specifies that the test project isn't built before being run. It also implicitly sets the --no-restore flag.

  • --no-restore

    Specifies that an implicit restore isn't executed when running the command.

  • --no-ansi

    Disables outputting ANSI escape characters to screen.

  • --no-progress

    Disables reporting progress to screen.

  • --output <VERBOSITY_LEVEL>

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

  • --no-launch-profile

    Don't attempt to use launchSettings.json to configure the application. By default, launchSettings.json is used, which can apply environment variables and command-line arguments to the test executable.

  • --no-launch-profile-arguments

    Don't use arguments specified by commandLineArgs in launch profile to run the application.

  • --property:<NAME>=<VALUE>

    Sets one or more MSBuild properties. Specify multiple properties by repeating the option:

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    The short form -p can be used for --property. The same applies for /property:property=value and its short form is /p. More information about the available arguments can be found in the dotnet msbuild documentation.

  • -?|-h|--help

    Prints out a description of how to use the command.

  • args

    Specifies extra arguments to pass 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.

    Tip

    To specify extra arguments for specific projects, use the TestingPlatformCommandLineArguments MSBuild property.

Note

To enable trace logging to a file, use the environment variable DOTNET_CLI_TEST_TRACEFILE to provide the path to the trace file.

Examples

  • Run the tests in the project or solution in the current directory:

    dotnet test

  • Run the tests in the TestProject project:

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

  • Run the tests in the TestProjects solution:

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

  • Run the tests using TestProject.dll assembly:

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

  • Run the tests using TestProject.dll assembly with the root directory:

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

  • Run the tests in the current directory with code coverage:

    dotnet test --coverage

  • Run the tests in the TestProject project, providing the -bl (binary log) argument to msbuild:

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

  • Run the tests in the TestProject project, setting the MSBuild DefineConstants property to DEV:

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"

See also

  • Last updated on