teste dotnet com Microsoft.Testing.Platform (MTP)

Esso artigo se aplica a: ✔️ .NET 10 SDK e versões posteriores

Nome

dotnet test – .NET driver de teste usado para executar testes de unidade com Microsoft.Testing.Platform.

Sinopse

dotnet test
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>] 
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <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

Com a Plataforma de Testes da Microsoft, dotnet test opera mais rápido do que com o VSTest. Os argumentos relacionados ao teste não são mais corrigidos, pois estão vinculados às extensões registradas nos project(s) de teste). Além disso, o MTP dá suporte a um filtro de globbing ao executar testes. Para obter mais informações, consulte Microsoft.Testing.Platform.

Aviso

Quando Microsoft.Testing.Platform é optado por global.json, dotnet test espera que todos os projetos de teste usem Microsoft.Testing.Platform. Será um erro se algum dos projetos de teste usar o VSTest.

Restauração implícita

Você não precisa executar dotnet restore porque ela é executada implicitamente por todos os comandos que exigem que uma restauração ocorra, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishe dotnet pack. Para desabilitar a restauração implícita, use a opção --no-restore.

O comando dotnet restore ainda é útil em determinados cenários em que a restauração explícita faz sentido, como compilações de integração continuosas no Azure DevOps Services ou em sistemas de build que precisam controlar explicitamente quando a restauração ocorre.

Para obter informações sobre como gerenciar feeds do NuGet, consulte a documentação dotnet restore.

Opções

Observação

Você pode usar apenas uma das seguintes opções por vez: --project, --solution ou --test-modules. Essas opções não podem ser combinadas. Além disso, ao usar --test-modules, não é possível especificar --arch, --configuration, --framework, --osou --runtime. Essas opções não são relevantes para um módulo já criado.

--project <PROJECT_PATH>

Especifica o caminho do arquivo project a ser executado (nome da pasta ou caminho completo). Se não é especificado, ele usa como padrão o diretório atual.
--solution <SOLUTION_PATH>

Especifica o caminho do arquivo de solução a ser executado (nome da pasta ou caminho completo). Se não é especificado, ele usa como padrão o diretório atual.
--test-modules <EXPRESSION>

Filtra módulos de teste usando o globbing de arquivo em .NET. Somente os testes pertencentes a esses módulos de teste serão executados. Para obter mais informações e exemplos sobre como usar o globbing de arquivo em .NET, consulte File globbing.
--root-directory <ROOT_PATH>

Especifica o diretório raiz da opção --test-modules. Ele só pode ser usado com a opção --test-modules.
--max-parallel-test-modules <NUMBER>

Especifica o número máximo de módulos de teste que podem ser executados em paralelo. O padrão é Environment.ProcessorCount.
--config-file <CONFIG_FILE>

Especifica o arquivo de configuração a ser usado para execução de teste. Se um caminho relativo for fornecido, ele será convertido em um caminho absoluto com base no diretório atual. Para obter mais informações sobre as configurações do arquivo de configuração, consulte testconfig.json.
--results-directory <RESULTS_DIRECTORY>

Especifica o diretório em que os resultados do teste são armazenados. Se o diretório não existir, ele será criado. Se um caminho relativo for fornecido, ele será convertido em um caminho absoluto com base no diretório atual.
--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

Especifica o diretório em que a saída de diagnóstico é armazenada. Se o diretório não existir, ele será criado. Se um caminho relativo for fornecido, ele será convertido em um caminho absoluto com base no diretório atual.
--minimum-expected-tests <NUMBER>

Especifica o número mínimo de testes que devem ser executados. Se o número real de testes for menor que o mínimo especificado, a execução do teste falhará com o código de saída 9. Para obter mais informações sobre códigos de saída, consulte códigos de saída Microsoft.Testing.Platform.
-a|--arch <ARCHITECTURE>

Especifica a arquitetura de destino. Essa é uma sintaxe abreviada para definir o RID (Identificador de Runtime), em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um computador win-x64, a especificação de --arch x86 define o RID como win-x86. Se você usar essa opção, não use a opção -r|--runtime. Disponível desde .NET 6 Versão Prévia 7.
-c|--configuration <CONFIGURATION>

Define a configuração de build. O padrão para a maioria dos projetos é Debug, mas você pode substituir as configurações de build em seu project.
-f|--framework <FRAMEWORK>

O TFM (Moniker da Estrutura de Destino) da estrutura de destino cujos testes serão executados. A estrutura de destino também deve ser especificada no arquivo project.
--os <OS>

Especifica o sistema operacional (SO) de destino. Essa é uma sintaxe abreviada para definir o RID (Identificador de Runtime), em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um computador win-x64, a especificação de --os linux define o RID como linux-x64. Se você usar essa opção, não use a opção -r|--runtime. Disponível desde .NET 6.
-r|--runtime <RUNTIME_IDENTIFIER>

O runtime de destino dos testes.

Formulário curto -r disponível a partir .NET SDK 7.

Observação

Não há suporte para a execução de testes para uma solução com uma propriedade global RuntimeIdentifier (explicitamente ou via --arch, --runtimeou --os) . Defina RuntimeIdentifier em um nível de project individual.
-v|--verbosity <LEVEL>

Define o nível de detalhes do comando. Os valores permitidos são q[uiet], m[inimal], n[ormal], d[etailed] e diag[nostic]. Para obter mais informações, consulte LoggerVerbosity.
--no-build

Especifica que o project de teste não foi criado antes de ser executado. Ele também define implicitamente o sinalizador --no-restore.
--no-restore

Especifica que uma restauração implícita não é executada ao executar o comando.
--no-ansi

Desabilita a saída de caracteres de escape ANSI para a tela.
--no-progress

Desabilita o progresso do relatório na tela.
--output <VERBOSITY_LEVEL>

Especifica a verbosidade de saída ao relatar testes. Os valores válidos são Normal e Detailed. O padrão é Normal.
--no-launch-profile

Não tente usar launchSettings.json para configurar o aplicativo. Por padrão, launchSettings.json é usado, o que pode aplicar variáveis de ambiente e argumentos de linha de comando ao executável de teste.
--no-launch-profile-arguments

Não use argumentos especificados pelo commandLineArgs perfil de inicialização para executar o aplicativo.
--property:<NAME>=<VALUE>

Define uma ou mais propriedades do MSBuild. Especifique várias propriedades repetindo a opção:
```
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
```
O formulário curto -p pode ser usado para --property. O mesmo se aplica a /property:property=value e sua forma curta é /p. Mais informações sobre os argumentos disponíveis podem ser encontradas na documentação do dotnet msbuild.
-?|-h|--help

Imprime uma descrição de como usar o comando.
args

Especifica argumentos extras a serem passados para os aplicativos de teste. Use um espaço para separar vários argumentos. Para obter mais informações e exemplos sobre o que passar, consulte a visão geral do Microsoft.Testing.Platform e os recursos do Microsoft.Testing.Platform.

Dica

Para especificar argumentos extras para projetos específicos, use a propriedade TestingPlatformCommandLineArguments MSBuild.

Observação

Para habilitar o registro em log de rastreamento em um arquivo, use a variável de ambiente DOTNET_CLI_TEST_TRACEFILE para fornecer o caminho para o arquivo de rastreamento.

Exemplos

Execute os testes no project ou solução no diretório atual:
```
dotnet test
```

Execute os testes no TestProject project:

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

Execute os testes na solução TestProjects:

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

Executar os testes usando o assembly TestProject.dll:

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

Execute os testes usando TestProject.dll assembly com o diretório raiz:

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

Execute os testes no diretório atual com cobertura de código:
```
dotnet test --coverage
```
Execute os testes e armazene os resultados em um diretório específico:
```
dotnet test --results-directory ./TestResults
```
Execute os testes com a saída de diagnóstico em um diretório específico:
```
dotnet test --diagnostic-output-directory ./Diagnostics
```
Execute os testes garantindo que pelo menos 10 testes sejam executados:
```
dotnet test --minimum-expected-tests 10
```
Execute os testes no TestProject project, fornecendo o argumento -bl (log binário) para msbuild:
```
dotnet test --project ./TestProject/TestProject.csproj -bl
```
Execute os testes no TestProject project, definindo a propriedade DefineConstants do MSBuild como DEV:
```
dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"
```

Consulte também

Comentários

Esta página foi útil?

Last updated on 2026-03-11