Compartilhar via

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>]
    [--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 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.

  • --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 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 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 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

  • Last updated on