This article applies to: ✔️ .NET Core 2.1 SDK and later versions
dotnet test - .NET test driver used to execute unit tests.
dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL>] [-a|--test-adapter-path <PATH_TO_ADAPTER>] [--blame] [-c|--configuration <CONFIGURATION>] [--collect <DATA_COLLECTOR_FRIENDLY_NAME>] [-d|--diag <PATH_TO_DIAGNOSTICS_FILE>] [-f|--framework <FRAMEWORK>] [--filter <EXPRESSION>] [--interactive] [-l|--logger <LOGGER_URI/FRIENDLY_NAME>] [--no-build] [--nologo] [--no-restore] [-o|--output <OUTPUT_DIRECTORY>] [-r|--results-directory <PATH>] [--runtime <RUNTIME_IDENTIFIER>] [-s|--settings <SETTINGS_FILE>] [-t|--list-tests] [-v|--verbosity <LEVEL>] [[--] <RunSettings arguments>] dotnet test -h|--help
dotnet test command is used to execute unit tests in a given solution. The
dotnet test command builds the solution and runs a test host application for each test project in the solution. The test host executes tests in the given project using a test framework, for example: MSTest, NUnit, or xUnit, and reports the success or failure of each test. If all tests are successful, the test runner returns 0 as an exit code; otherwise if any test fails, it returns 1.
For multi-targeted projects, tests are run for each targeted framework. The test host and the unit test framework are packaged as NuGet packages and are restored as ordinary dependencies for the project.
Test projects specify the test runner using an ordinary
<PackageReference> element, as seen in the following sample project file:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp2.2</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.5.0" /> <PackageReference Include="xunit" Version="2.4.1" /> <PackageReference Include="xunit.runner.visualstudio" Version="2.4.1" /> </ItemGroup> </Project>
Microsoft.NET.Test.Sdk is the test host,
xunit is the test framework. And
xunit.runner.visualstudio is a test adapter, which allows the xUnit framework to work with the test host.
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 publish, and
dotnet pack. To disable implicit restore, use 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.
PROJECT | SOLUTION | DIRECTORY | DLL
- Path to the test project.
- Path to the solution.
- Path to a directory that contains a project or a solution.
- Path to a test project .dll file.
If not specified, it searches for a project or a solution in the current directory.
Path to a directory to be searched for additional test adapters. Only .dll files with suffix
.TestAdapter.dllare inspected. If not specified, the directory of the test .dll is searched.
Runs the tests in blame mode. This option is helpful in isolating problematic tests that cause the test host to crash. When a crash is detected, it creates a sequence file in
TestResults/<Guid>/<Guid>_Sequence.xmlthat captures the order of tests that were run before the crash.
Defines the build configuration. The default value is
Debug, but your project's configuration could override this default SDK setting.
Enables data collector for the test run. For more information, see Monitor and analyze test run.
To collect code coverage on any platform that is supported by .NET Core, install Coverlet and use the
--collect:"XPlat Code Coverage"option.
On Windows, you can collect code coverage by using the
--collect "Code Coverage"option. This option generates a .coverage file, which can be opened in Visual Studio 2019 Enterprise. For more information, see Use code coverage and Customize code coverage analysis.
Enables diagnostic mode for the test platform and writes diagnostic messages to the specified file and to files next to it. The process that is logging the messages determines which files are created, such as
*.host_<date>.txtfor test host log, and
*.datacollector_<date>.txtfor data collector log.
Forces the use of
dotnetor .NET Framework test host for the test binaries. This option only determines which type of host to use. The actual framework version to be used is determined by the runtimeconfig.json of the test project. When not specified, the TargetFramework assembly attribute is used to determine the type of host. When that attribute is stripped from the .dll, the .NET Framework host is used.
Filters out tests in the current project using the given expression. For more information, see the Filter option details section. For more information and examples on how to use selective unit test filtering, see Running selective unit tests.
Prints out a short help for the command.
Allows the command to stop and wait for user input or action. For example, to complete authentication. Available since .NET Core 3.0 SDK.
Specifies a logger for test results. Unlike MSBuild, dotnet test doesn't accept abbreviations: instead of
Doesn't build the test project before running it. It also implicitly sets the -
Run tests without displaying the Microsoft TestPlatform banner. Available since .NET Core 3.0 SDK.
Doesn't execute an implicit restore when running the command.
Directory in which to find the binaries to run. If not specified, the default path is
./bin/<configuration>/<framework>/. For projects with multiple target frameworks (via the
TargetFrameworksproperty), you also need to define
--frameworkwhen you specify this option.
dotnet testalways runs tests from the output directory. You can use AppDomain.BaseDirectory to consume test assets in the output directory.
The directory where the test results are going to be placed. If the specified directory doesn't exist, it's created. The default is
TestResultsin the directory that contains the project file.
The target runtime to test for.
.runsettingsfile to use for running the tests. The
TargetPlatformelement (x86|x64) has no effect for
dotnet test. To run tests that target x86, install the x86 version of .NET Core. The bitness of the dotnet.exe that is on the path is what will be used for running tests. For more information, see the following resources:
List all of the discovered tests in the current project.
Sets the verbosity level of the command. Allowed values are
diag[nostic]. The default is
minimal. For more information, see LoggerVerbosity.
RunSettings are passed as the last arguments on the command line after "-- " (note the space after --). Inline
RunSettings are specified as
[name]=[value] pairs. A space is used to separate multiple
dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True
For more information, see Passing RunSettings arguments through command line.
Run the tests in the project in the current directory:
Run the tests in the
dotnet test ~/projects/test1/test1.csproj
Run the tests in the project in the current directory, and generate a test results file in the trx format:
dotnet test --logger trx
Run the tests in the project in the current directory, and generate a code coverage file (after installing Coverlet):
dotnet test --collect:"XPlat Code Coverage"
Run the tests in the project in the current directory, and generate a code coverage file (Windows only):
dotnet test --collect "Code Coverage"
Run the tests in the project in the current directory, and log with detailed verbosity to the console:
dotnet test --logger "console;verbosity=detailed"
- Run the tests in the project in the current directory, and report tests that were in progress when the test host crashed:
dotnet test --blame
Filter option details
<Expression> has the format
<property> is an attribute of the
Test Case. The following are the properties supported by popular unit test frameworks:
|Test Framework||Supported properties|
<operator> describes the relationship between the property and the value:
||Not exact match|
<value> is a string. All the lookups are case insensitive.
An expression without an
<operator> is automatically considered as a
FullyQualifiedName property (for example,
dotnet test --filter xyz is same as
dotnet test --filter FullyQualifiedName~xyz).
Expressions can be joined with conditional operators:
You can enclose expressions in parenthesis when using conditional operators (for example,
(Name~TestMethod1) | (Name~TestMethod2)).
For more information and examples on how to use selective unit test filtering, see Running selective unit tests.