teste dotnet com Microsoft.Testing.Platform (MTP)

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

Nome

dotnet test - Driver de teste do .NET 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>]
    [-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 projetos 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 builds de integração contínua no do 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 de cada vez: --project, ou --solution--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 de projeto 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 no .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 no .NET, consulte Arquivo 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.
-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 a versão prévia 7 do .NET 6.
-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 projeto.
-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 precisa ser especificada no arquivo de projeto.
--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 o .NET 6.
-r|--runtime <RUNTIME_IDENTIFIER>

O runtime de destino dos testes.

Formulário curto -r disponível a partir do SDK do .NET 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) . Em vez disso, defina RuntimeIdentifier em um nível de projeto 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 projeto 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 de visão geral do Microsoft.Testing.Platform e extensões 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 projeto ou na solução no diretório atual:
```
dotnet test
```

Execute os testes no projeto TestProject:

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 no projeto TestProject, fornecendo o argumento -bl (log binário) para msbuild:
```
dotnet test --project ./TestProject/TestProject.csproj -bl
```
Execute os testes no projeto TestProject, 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-01-06