Visão geral do Microsoft.Testing.Platform

O Microsoft.Testing.Platform é uma alternativa leve e portátil ao VSTest para executar testes em todos os contextos, incluindo pipelines de CI (integração contínua), CLI, Gerenciador de Teste do Visual Studio, Gerenciador de Teste do VS Code. O Microsoft.Testing.Platform é inserido diretamente em seus projetos de teste e não há dependências de outro aplicativo, como vstest.console ou dotnet test, necessários para executar seus testes.

Microsoft.Testing.Platform é de código aberto. Você pode encontrar o código Microsoft.Testing.Platform no repositório do Git microsoft/testfx.

Pilares Microsoft.Testing.Platform

Esta nova plataforma de testes foi criada com base na experiência da equipe de testes de experiência do desenvolvedor .NET e visa abordar os desafios encontrados desde o lançamento do .NET Core em 2016. Embora haja um alto nível de compatibilidade entre o .NET Framework e o .NET Core/.NET, alguns recursos importantes, como o sistema de plug-ins e os novos possíveis fatores de formulários de compilações do .NET, tornaram complexo evoluir ou oferecer suporte total ao novo recurso de runtime com a arquitetura atual da Plataforma VSTest.

Os principais fatores que impulsionam a evolução da nova plataforma de testes são detalhados a seguir:

• Determinismo: garantir que a execução dos mesmos testes em diferentes contextos (local, CI) produzirá o mesmo resultado. O novo tempo de execução não depende de reflexão ou de qualquer outro recurso dinâmico de tempo de execução do .NET para coordenar uma execução de teste.

• Transparência de runtime: o runtime do teste não interfere no código do framework de teste, não cria contextos isolados como AppDomain ou AssemblyLoadContext e não usa reflexão ou resolvedores personalizados para assembly.

• Registro de extensões em tempo de compilação: extensões, como estruturas de teste e extensões dentro/fora do processo, são registradas durante o tempo de compilação para garantir o determinismo e facilitar a detecção de inconsistências.

• Dependências zero: o núcleo da plataforma é um único assembly .NET, Microsoft.Testing.Platform.dll, que não tem dependências além dos runtimes suportados.

• Hospedável: o runtime do teste pode ser hospedado em qualquer aplicativo .NET. Embora um aplicativo de console seja comumente usado para executar testes, você pode criar um aplicativo de teste em qualquer tipo de aplicativo .NET. Isso permite que você execute testes em contextos especiais, como dispositivos ou navegadores, onde pode haver limitações.

• Suporte a todos os formatos .NET: suporte aos formatos .NET atuais e futuros, incluindo AOT nativo.

• Alto desempenho: encontrar o equilíbrio certo entre recursos e pontos de extensão para evitar sobrecarregar o runtime com código não fundamental. A nova plataforma de testes foi projetada para "orquestrar" uma execução de teste, em vez de fornecer detalhes de implementação sobre como fazer isso.

• Extensível o suficiente: a nova plataforma é construída sobre pontos de extensibilidade para garantir a personalização máxima da execução de runtime. Ele permite que você configure o host do processo de teste, observe o processo de teste e consuma informações do framework de teste dentro do processo de host de teste.

• Implantação de módulo único: o recurso de hospedagem permite um modelo de implantação de módulo único, em que um único resultado de compilação pode ser usado para dar suporte a todos os pontos de extensibilidade, tanto fora quanto no processo, sem a necessidade de enviar diferentes módulos executáveis.

Estruturas de teste com suporte

• MSTest. No MSTest, o suporte de Microsoft.Testing.Platform é feito por meio do executor do MSTest.
• NUnit. No NUnit, o suporte de Microsoft.Testing.Platform é feito por meio do executor do NUnit.
• xUnit.net: Em xUnit.net, o suporte de Microsoft.Testing.Platform é feito via executor xUnit.net.
• TUnit: totalmente criado com base na Microsoft.Testing.Platform. Para obter mais informações, consulte a documentação do TUnit.

Executar e depurar testes

Os projetos de teste do Microsoft.Testing.Platform são criados como executáveis que podem ser executados (ou depurados) diretamente. Não há nenhum console ou comando de execução de teste extra. O aplicativo encerra com um código de saída diferente de zero em caso de erro, o que é típico na maioria dos executáveis. Para obter mais informações sobre os códigos de saída conhecidos, consulte Códigos de saída do Microsoft.Testing.Platform.

<TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>

dotnet run --project Contoso.MyTests

dotnet exec Contoso.MyTests.dll

dotnet Contoso.MyTests.dll

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

dotnet test Contoso.MyTests.dll

- task: CmdLine@2
  displayName: "Run Contoso.MyTests"
  inputs:
    script: '.\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Opções

A lista abaixo descreve apenas as opções da plataforma. Para ver as opções específicas oferecidas por cada extensão, confira a página de documentação da extensão ou use a opção --help.

• @

  Especifica o nome do arquivo de resposta. O nome do arquivo de resposta deve seguir imediatamente o caractere @ sem espaço em branco entre o caractere @ e o nome do arquivo de resposta.

  As opções em um arquivo de resposta são interpretadas como se estivessem presentes naquele lugar na linha de comando. Cada argumento em um arquivo de resposta deve começar e terminar na mesma linha. Você não pode usar o caractere de barra invertida () para concatenar linhas. O uso de um arquivo de resposta ajuda para comandos muito longos que podem exceder os limites de terminal. Você pode combinar um arquivo de resposta com argumentos de linha de comando embutidos. Por exemplo:

  ./TestExecutable.exe @"filter.rsp" --timeout 10s
  

  em que filter.rsp pode ter o seguinte conteúdo:

  --filter "A very long filter"
  

  Ou um único arquivo rsp pode ser usado para especificar o tempo limite e o filtro da seguinte maneira:

  ./TestExecutable.exe @"arguments.rsp"
  

  --filter "A very long filter"
  --timeout 10s
  

• --config-file

  Especifica um arquivo testconfig.json.

• --diagnostic

  Habilita o log de diagnóstico. O nível de log padrão é Trace. O arquivo é escrito no diretório de saída com o seguinte formato de nome, log_[MMddHHssfff].diag.

• --diagnostic-filelogger-synchronouswrite

  Força o logger de arquivos embutido a gravar logs de forma síncrona. Útil para cenários em que você não deseja perder nenhuma entrada de log (se o processo falhar). Isso reduz a velocidade da execução do teste.

• --diagnostic-output-directory

  O diretório de saída do log de diagnóstico, se não for especificado, o arquivo será gerado no diretório padrão TestResults.

• --diagnostic-output-fileprefix

  O prefixo do nome do arquivo de log. Usa "log_" como padrão.

• --diagnostic-verbosity

  Define o nível de detalhamento quando a opção --diagnostic é usada. Os valores disponíveis são Trace, Debug, Information, Warning, Errorou Critical.

• --exit-on-process-exit

  Saia do processo de teste quando o processo dependente for encerrado. O PID deve ser fornecido.

• --help

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

• --ignore-exit-code

  Permite que alguns códigos de saída diferentes de zero sejam ignorados e, em vez disso, retornados como 0. Para obter mais informações, consulte Ignorar códigos de saída específicos.

• --info

  Exibe informações avançadas sobre o aplicativo de teste .NET, como:

  • A plataforma.
  • O ambiente.
  • Cada provedor de linha de comando registrado, como name, version, description e options.
  • Cada ferramenta registrada, como command, name, version e description, e todos os provedores de linha de comando.

  Este recurso é usado para entender as extensões que estariam registrando a mesma opção de linha de comando ou as alterações nas opções disponíveis entre várias versões de uma extensão (ou da plataforma).

• --list-tests

  Liste os testes disponíveis. Os testes não serão executados.

• --maximum-failed-tests

  Especifica o número máximo de falhas de testes que, quando atingidas, interromperão a execução do teste. O suporte para essa opção requer que os autores do framework implementem a funcionalidade IGracefulStopTestExecutionCapability. O código de saída ao atingir essa quantidade de falhas de teste é 13. Para obter mais informações, consulte Códigos de saída de Microsoft.Testing.Platform.

  Observação

  Esse recurso está disponível no Microsoft.Testing.Platform a partir da versão 1.5.

• --minimum-expected-tests

  Especifica o número mínimo de testes que devem ser executados. Por padrão, espera-se que pelo menos um teste seja executado.

• --results-directory

  O diretório em que os resultados de teste serão colocados. Se o diretório especificado não existir, ele será criado. O padrão é TestResults no diretório que contém o aplicativo de teste.

• --timeout

  Um tempo limite global de execução de teste. Usa um argumento como string no formato <value>[h|m|s], em que <value> é flutuante.

Integração do MSBuild

O pacote NuGet Microsoft.Testing.Platform.MSBuild fornece várias integrações para a Microsoft.Testing.Platform com o MSBuild:

• Suporte para dotnet test. Para obter mais informações, consulte Testando com dotnet test.
• Suporte para ProjectCapability obrigatório para o Visual Studio e os Visual Studio Code Exploradores de Testes.
• Geração automática do ponto de entrada (método Main).
• Geração automática do arquivo de configuração.

Consulte também

• Comparação entre Microsoft.Testing.Platform e VSTest
• Extensões Microsoft.Testing.Platform
• Telemetria Microsoft.Testing.Platform
• Códigos de saída Microsoft.Testing.Platform