Visão geral do Microsoft.Testing.Platform
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 Microsoft.Testing.Platform
código no repositório GitHub da microsoft/testfx .
Pilares Microsoft.Testing.Platform
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 plug-ins e os novos possíveis fatores forma das compilações .NET, tornaram complexo evoluir ou oferecer suporte total ao novo recurso de tempo de execução com a arquitetura de plataforma VSTest atual.
Os principais fatores determinantes para a evolução da nova plataforma de testes são detalhados a seguir:
Determinismo: Garantir que a execução dos mesmos testes em contextos diferentes (local, IC) 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
ouAssemblyLoadContext
e não usa reflexão ou resolvedores de assembly personalizados.Registro de extensões em tempo de compilação: 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.Hospedável: O tempo de execução 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 fatores forma .NET: ofereça suporte a fatores forma .NET atuais e futuros, incluindo AOT nativo.
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 extensibilidade para permitir a máxima personalização da execução em tempo de 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 do processo quanto em processo, sem a necessidade de enviar diferentes módulos executáveis.
Estruturas de teste suportadas
- MSTest. No MSTest, o suporte é
Microsoft.Testing.Platform
feito via corredor MSTest. - NUnit. No NUnit, o suporte é
Microsoft.Testing.Platform
feito via NUnit runner. - xUnit.net: Em xUnit.net, o apoio é
Microsoft.Testing.Platform
feito via xUnit.net corredor. - TUnit: inteiramente construído sobre o , para obter mais informações, consulte a
Microsoft.Testing.Platform
documentação do TUnit
Executar e depurar testes
Microsoft.Testing.Platform
Os projetos de teste são construídos 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, como é típico na maioria dos executáveis. Para obter mais informações sobre os códigos de saída conhecidos, consulte Microsoft.Testing.Platform exit codes.
Importante
Por padrão, Microsoft.Testing.Platform
coleta telemetria. Para obter mais informações e opções sobre como desativar, consulte Telemetria Microsoft.Testing.Platform.
Publicar o projeto de teste usando dotnet publish
e executando o aplicativo diretamente é outra maneira de executar seus testes. Por exemplo, executando o ./Contoso.MyTests.exe
arquivo . Em alguns cenários, também é viável usar dotnet build
para produzir o executável, mas pode haver casos de borda a considerar, como AOT nativo.
Utilizar o comando dotnet run
O dotnet run
comando 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. O uso 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
o , consulte dotnet run.
Utilizar o comando dotnet exec
O dotnet exec
comando or 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
or
dotnet Contoso.MyTests.dll
Nota
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
o , consulte dotnet exec.
Utilizar o comando dotnet test
Microsoft.Testing.Platform
oferece uma camada de compatibilidade com vstest.console.exe
e dotnet test
garante que você possa executar seus testes como antes, permitindo 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 --help
opção.
--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 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 log de diagnóstico, se não especificado o arquivo é gerado no diretório TestResults padrão.
--diagnostic-output-fileprefix
O prefixo do nome do arquivo de log. O padrão é "log_"
.
--diagnostic-verbosity
Define o nível de detalhamento quando o --diagnostic
switch é usado. Os valores disponíveis são Trace
, Debug
, Information
, Warning
, Error
, ou Critical
.
--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 seu,
name
,description
version
eoptions
. - Cada ferramenta registrada, como seu,
command
,name
,version
,description
e 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.
--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 está TestResults
no diretório que contém o aplicativo de teste.
Integração com MSBuild
O pacote NuGet Microsoft.Testing.Platform.MSBuild fornece várias integrações com Microsoft.Testing.Platform
o MSBuild:
- Suporte para
dotnet test
. Para obter mais informações, consulte dotnet test integration. - Suporte para
ProjectCapability
requeridosVisual Studio
eVisual Studio Code
exploradores de teste. - Geração automática do ponto de entrada (
Main
método). - Geração automática do arquivo de configuração.
Nota
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 IsTestingPlatformApplication
propriedade MSBuild.