Partilhar via

teste dotnet com Microsoft.Testing.Platform (MTP)

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

Nome

dotnet test - .NET driver de teste usado para executar testes unitários com o 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 Microsoft Testing Platform, dotnet test opera mais rápido do que com o VSTest. Os argumentos relacionados com testes já não são fixos, pois estão ligados às extensões registadas no(s) projecto(s) de teste. Além disso, o MTP suporta um filtro de globbing ao executar testes. Para obter mais informações, consulte Microsoft.Testing.Platform.

Advertência

Quando Microsoft.Testing.Platform é aceito via global.json, dotnet test espera que todos os projetos de teste usem Microsoft.Testing.Platform. É um erro se qualquer um dos projetos de teste usar VSTest.

Restauração implícita

Não é necessário executádotnet restore porque ele é executado implicitamente por todos os comandos que exigem uma restauração para ocorrer, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishe dotnet pack. Para desativar a restauração implícita, use a opção --no-restore.

O comando dotnet restore continua a ser útil em certos cenários onde a restauração explícita faz sentido, como compilações de integração contínua em Azure DevOps Services ou em sistemas de compilação que precisam de controlar explicitamente quando ocorre a restauração.

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

Opções

Observação

Pode usar apenas uma das seguintes opções de cada 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. Estas opções não são relevantes para um módulo já construído.

  • --project <PROJECT_PATH>

    Especifica o caminho do ficheiro do project a executar (nome da pasta ou caminho completo). Se não for especificado, o padrão será 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 for especificado, o padrão será o diretório atual.

  • --test-modules <EXPRESSION>

    Filtra módulos de teste usando globo de ficheiros em .NET. Apenas os testes pertencentes a esses módulos de teste serão executados. Para mais informações e exemplos sobre como usar o globbing de ficheiros em .NET, consulte 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. A predefinição é Environment.ProcessorCount.

  • --config-file <CONFIG_FILE>

    Especifica o ficheiro de configuração a usar para execução de testes. Se for fornecido um caminho relativo, este é convertido num caminho absoluto baseado no diretório atual. Para mais informações sobre as definições do ficheiro de configuração, vejatestconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Especifica o diretório onde os resultados dos testes são armazenados. Se o diretório não existir, é criado. Se for fornecido um caminho relativo, este é convertido num caminho absoluto baseado no diretório atual.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Especifica o diretório onde a saída de diagnóstico é armazenada. Se o diretório não existir, é criado. Se for fornecido um caminho relativo, este é convertido num caminho absoluto baseado 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 inferior ao mínimo especificado, a execução falha com o código de saída 9. Para mais informações sobre códigos de saída, consulte códigos de saída do Microsoft.Testing.Platform.

  • -a|--arch <ARCHITECTURE>

    Especifica a arquitetura de destino. Esta é uma sintaxe abreviada para definir o Runtime Identifier (RID), onde o valor fornecido é combinado com o RID padrão. Por exemplo, em uma win-x64 máquina, especificar --arch x86 define o RID como win-x86. Se você usar essa opção, não use a -r|--runtime opção. Disponível desde .NET 6 Preview 7.

  • -c|--configuration <CONFIGURATION>

    Define a configuração de compilação. O padrão para a maioria dos projetos é Debug, mas podes sobrescrever as definições de configuração da build no teu project.

  • -f|--framework <FRAMEWORK>

    O moniker da estrutura de destino (TFM) da estrutura de destino para a qual executar testes. O framework alvo também deve ser especificado no ficheiro do project.

  • --os <OS>

    Especifica o sistema operacional (SO) de destino. Esta é uma sintaxe abreviada para definir o Runtime Identifier (RID), onde o valor fornecido é combinado com o RID padrão. Por exemplo, em uma win-x64 máquina, especificar --os linux define o RID como linux-x64. Se você usar essa opção, não use a -r|--runtime opção. Disponível desde o .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    O tempo de execução de destino para testar.

    A forma curta -r disponível a partir .NET SDK 7.

    Observação

    Executar testes para uma solução com uma propriedade global RuntimeIdentifier (explicitamente ou via --arch, --runtime, ou --os) não é suportado. Defina RuntimeIdentifier num nível de project individual em vez disso.

  • -v|--verbosity <LEVEL>

    Define o nível de verbosidade 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 é construído antes de ser executado. Também estabelece implicitamente a bandeira --no-restore.

  • --no-restore

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

  • --no-ansi

    Desativa a saída de caracteres de escape ANSI para a tela.

  • --no-progress

    Desabilita o relatório de progresso para a tela.

  • --output <VERBOSITY_LEVEL>

    Especifica a verbosidade de saída ao relatar testes. Os valores válidos são Normal e Detailed. A predefinição é Normal.

  • --no-launch-profile

    Não tentes usar launchSettings.json para configurar a aplicação. Por padrão, launchSettings.json é usado, que pode aplicar variáveis de ambiente e argumentos de linha de comando ao executável de teste.

  • --no-launch-profile-arguments

    Não uses argumentos especificados por commandLineArgs no perfil de lançamento para executar a aplicação.

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

    Define uma ou mais propriedades do MSBuild. Especifique várias propriedades repetindo a opção:

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

    A forma -p abreviada pode ser usada para --property. O mesmo se aplica à /property:property=value e a sua forma abreviada é /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 o(s) aplicativo(s) de teste. Use um espaço para separar vários argumentos. Para mais informações e exemplos sobre o que passar, consulte a visão geral do Microsoft.Testing.Platform e as funcionalidades do Microsoft.Testing.Platform.

    Sugestão

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

Observação

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

Examples

  • Execute os testes no project ou solução no diretório atual:

    dotnet test

  • Executa os testes no TestProject project:

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

  • Execute os testes na solução TestProjects:

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

  • Execute os testes usando TestProject.dll assembly:

    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

  • Executa os testes e armazena os resultados num diretório específico:

    dotnet test --results-directory ./TestResults

  • Execute os testes com saída de diagnóstico numa diretório específica:

    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 (logarítrum binário) a msbuild:

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

  • Execute os testes no TestProject project, definindo a propriedade MSBuild DefineConstants para DEV:

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

Consulte também

  • Last updated on