Partilhar via

Visão geral do Microsoft.Testing.Platform

  • Artigo

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

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

Pilares da Plataforma Microsoft.Testing

Esta nova plataforma de teste baseia-se na experiência da equipa de Testes de Experiência do Programador .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 extensões e os novos possíveis formatos das compilações .NET, tornaram complexo evoluir ou oferecer suporte total à nova funcionalidade em tempo de execução com a arquitetura da plataforma VSTest atual.

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

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

  • Transparência do tempo de execução: O tempo de execução do teste não interfere com o código da estrutura de teste, não cria contextos isolados como AppDomain ou AssemblyLoadContexte não usa resolvedores de reflexão ou assembly personalizados.

  • Registro em tempo de compilação de extensões: Extensões, como estruturas de teste e extensões in/out-of-process, são registradas durante o tempo de compilação para garantir determinismo e facilitar a deteção de inconsistências.

  • Zero dependências: O núcleo da plataforma é um único assembly .NET, Microsoft.Testing.Platform.dll, que não tem dependências além dos tempos de execução suportados.

  • Hostable: O ambiente de execução de testes pode ser hospedado em qualquer aplicação .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.

  • Ofereça suporte a todos os fatores de forma .NET: Ofereça suporte a fatores de forma .NET atuais e futuros, incluindo Native AOT.

  • Performant: Encontrar o equilíbrio certo entre recursos e pontos de extensão para evitar o inchaço do tempo de execução com código não fundamental. A nova plataforma de teste foi projetada para "orquestrar" uma execução de teste, em vez de fornecer detalhes de implementação sobre como fazê-lo.

  • Extensível o suficiente: A nova plataforma é construída em pontos de extensão para permitir a máxima personalização durante a execução. Ele permite que você configure o host do processo de teste, observe o processo de teste e consuma informações da estrutura de teste dentro do processo do host de teste.

  • implantação de módulo único: O recurso de hostability permite um modelo de implantação de módulo único, onde um único resultado de compilação pode ser usado para suportar todos os pontos de extensibilidade, tanto fora de processo como em processo, sem a necessidade de entregar diferentes módulos executáveis.

Estruturas de teste suportadas

  • MSTest. No MSTest, o suporte de Microsoft.Testing.Platform é feito através de corredor MSTest.
  • NUnit. Em NUnit, o Microsoft.Testing.Platform é suportado através do executor NUnit .
  • Em xUnit.net, o suporte de Microsoft.Testing.Platform é feito através do executor do xUnit.net.
  • TUnit: inteiramente construído sobre o Microsoft.Testing.Platform, para obter mais informações, consulte a documentação do TUnit em .

Executar e depurar testes

Microsoft.Testing.Platform projetos de teste 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 sai com um código de saída diferente de zero se houver um erro, o que é típico para a maioria dos executáveis. Para obter mais informações sobre os códigos de saída conhecidos, consulte Microsoft.Testing.Platform códigos de saída.

Dica

Você pode ignorar um código de saída de específico usando a opção de linha de comando --ignore-exit-code.

Você também pode definir opções de linha de comando que se aplicam a um projeto de teste específico no arquivo de projeto usando a propriedade TestingPlatformCommandLineArguments MSBuild. Um caso de uso comum é para projetos de teste que têm todos os testes ignorados, que normalmente sairão com o código de saída 8 (a sessão de teste executou zero testes). Nesse cenário, você pode adicionar o seguinte sob um PropertyGroup em seu arquivo de projeto:

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

Importante

Por padrão, Microsoft.Testing.Platform coleta telemetria. Para obter mais informações e opções para desativação, consulte a telemetria da Microsoft.Testing.Platform.

Publicar o projeto de teste usando dotnet publish e executando o aplicativo diretamente é outra maneira de executar seus testes. Por exemplo, executar o ./Contoso.MyTests.exe. Em alguns cenários, também é viável usar dotnet build para produzir o executável, mas podem haver casos especiais a considerar; por exemplo, AOT Nativo.

Use dotnet run

O comando dotnet run pode ser usado para criar e executar seu projeto de teste. Esta é a maneira mais fácil, embora às vezes mais lenta, de executar seus testes. Usar dotnet run é prático quando você está editando e executando testes localmente, porque garante que o projeto de teste seja reconstruído quando necessário. dotnet run também encontrará automaticamente o projeto na pasta atual.

dotnet run --project Contoso.MyTests

Para obter mais informações sobre dotnet run, veja dotnet run.

Use dotnet exec

O comando dotnet exec ou dotnet é usado para executar (ou executar) um projeto de teste já construído, esta é uma alternativa para executar o aplicativo diretamente. dotnet exec requer caminho para a DLL do projeto de teste compilado.

dotnet exec Contoso.MyTests.dll

ou

dotnet Contoso.MyTests.dll

Observação

Fornecer o caminho para o executável do projeto de teste (*.exe) resulta em um erro:

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'

Para obter mais informações sobre dotnet exec, consulte dotnet exec.

Use dotnet test

Microsoft.Testing.Platform oferece uma camada de compatibilidade com vstest.console.exe e dotnet test garantindo que você possa executar seus testes como antes enquanto habilita um novo cenário de execução.

dotnet test Contoso.MyTests.dll

Opções

A lista abaixo descreveu apenas as opções da plataforma. Para ver as opções específicas trazidas por cada extensão, consulte 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 local na linha de comando. Cada argumento em um arquivo de resposta deve começar e terminar na mesma linha. Não é possível usar o caractere de barra invertida () para concatenar linhas. Usar um arquivo de resposta ajuda para comandos muito longos que podem exceder os limites do terminal. Você pode combinar um arquivo de resposta com argumentos de linha de comando embutidos. Por exemplo:

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

    onde filter.rsp pode conter 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 é gravado no diretório de saída com o seguinte formato de nome, log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Força o registrador de arquivos interno 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 torna mais lenta a execução do teste.

  • --diagnostic-output-directory

    O diretório de saída do registo de diagnóstico, se não for especificado, então o ficheiro é gerado no diretório padrão TestResults.

  • --diagnostic-output-fileprefix

    O prefixo do nome do ficheiro de log. O padrão é "log_".

  • --diagnostic-verbosity

    Defina 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 se o processo dependente for encerrado. PID deverá 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, descriptione options.
    • Cada ferramenta registada, como command, name, version, description, bem como todos os provedores de linha de comando.

    Esse 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

    Listar 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 da estrutura implementem o recurso 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 Microsoft.Testing.Platform.

    Observação

    Esse recurso está disponível em 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 onde os resultados do 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

    Tempo limite global para a execução de testes. Usa um argumento como cadeia de caracteres no formato <value>[h|m|s] onde <value> é flutuante.

Integração com MSBuild

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

  • Suporte para dotnet test. Para obter mais informações, consulte dotnet test integration.
  • O suporte para ProjectCapability é necessário pelos Exploradores de Teste Visual Studio e Visual Studio Code.
  • Geração automática do ponto de entrada (métodoMain).
  • Geração automática do arquivo de configuração.

Observação

Essa integração funciona de forma transitiva (um projeto que faz referência a outro projeto que faz referência a este pacote se comportará como se fizesse referência ao pacote) e pode ser desabilitada por meio da propriedade IsTestingPlatformApplication MSBuild.

Ver também