Relatórios de testes

Cada opção de relatório requer o pacote de extensão nomeado na sua secção. Adicione o pacote diretamente, ou use uma configuração ou perfil do SDK de teste que o inclua. As extensões de relatório não fazem parte do núcleo MTP, por isso uma opção como --report-trx a não é reconhecida quando a aplicação de teste não regista a sua extensão. Execute a aplicação de teste com --help, ou execute dotnet test --help em modo MTP, para confirmar que existe uma opção disponível.

Nomes de ficheiros de relatório

Cada extensão de relatório escreve o seu ficheiro no diretório de resultados do teste, que podes definir com a --results-directory opção. Para substituir o nome, utilize a opção correspondente --report-*-filename. Cada secção do relatório indica o nome padrão desse relatório.

Um nome de ficheiro pode incluir um caminho relativo que permanece dentro do diretório de resultados de teste, e pode usar os seguintes itens de substituição (placeholders):

Por exemplo, --report-trx-filename "{asm}_{tfm}_{arch}.trx" reproduz o nome padrão TRX.

Se já existir um nome de ficheiro TRX, HTML ou JUnit predefinido ou explícito para uma origem de teste, a extensão emite um aviso e sobrescreve o ficheiro. A partir do MTP 2.4, o CTRF usa o mesmo comportamento. Para conservar o histórico do relatório, inclua {time}.

Consolidação de relatórios

A partir do MTP 2.4.0, o MTP pós-processa automaticamente artefactos de relatório após uma dotnet test invocação executar múltiplos módulos de teste ou após o suporte a retentativas executar múltiplas tentativas. A funcionalidade é experimental no MTP 2.4.0.

As extensões TRX, JUnit, CTRF e HTML agrupam artefactos compatíveis por tipo de relatório e escrevem um relatório consolidado no subdiretório do merged diretório de resultados de teste. A consolidação CTRF combina os resultados do módulo e agrega as novas tentativas no resultado final do teste, com o respetivo histórico de novas tentativas. A consolidação HTML cria um resumo fundido e preserva os relatórios originais por processo.

Para extensões de relatórios personalizadas, a API experimental IArtifactPostProcessor expõe modos separados TestModules e RetryAttempts de processamento. Para mais informações, consulte As IArtifactPostProcessor extensões.

Relatórios de teste do Visual Studio (TRX)

O ficheiro de resultados do Visual Studio (ou TRX) é o formato predefinido para publicar os resultados dos testes. Esta extensão requer o pacote Microsoft.Testing.Extensions.TrxReport NuGet.

Registo manual

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddTrxReportProvider();

Opções

O relatório é salvo dentro da pasta padrão TestResults que pode ser especificada por meio do argumento de linha de comando --results-directory.

Relatórios HTML

O relatório HTML cria um ficheiro HTML interativo e autónomo para uma sessão de teste. Esta extensão requer a Microsoft. Testing.Extensions.HtmlReport pacote NuGet.

Registo manual

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddHtmlReportProvider();

Opções

Relatórios do JUnit

O relatório JUnit cria um ficheiro XML compatível com JUnit para uma sessão de teste. Esta extensão requer a Microsoft. Testing.Extensions.JUnitReport pacote NuGet.

Registo manual

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddJUnitReportProvider();

Opções

Relatórios da CTRF

O relatório CTRF cria um ficheiro JSON que utiliza o Formato Comum de Relatório de Teste para uma sessão de teste. Esta extensão requer o pacote NuGet Microsoft.Testing.Extensions.CtrfReport.

Registo manual

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddCtrfReportProvider();

Opções

A partir do MTP 2.4, o CTRF preserva todos os resultados quando múltiplos testes usam o mesmo UID. Inclui também anexos de cada teste e de tentativas anteriores e deduz os respetivos tipos MIME a partir dos nomes dos ficheiros.

Para testes repetidos, a CTRF correlaciona as tentativas apenas quando a relação é inequívoca. Depois, regista tentativas anteriores em retryAttempts, define retries e assinala um resultado posterior com êxito como flaky: true. Resultados ambíguos do mesmo UID permanecem separados para que o relatório não associe diagnósticos ao teste errado.

A partir da versão preliminar do MTP 2.5, testId é derivado do UID completo do nó de teste MTP da estrutura. O repórter escapa de valores nos seus namespaces de identidade reservados e usa uma identidade SHA-256 determinística para UIDs longos em vez de os truncar. Cada execução reportada recebe um novo UUID em executionId, e tentativas anteriores recebem o seu próprio attemptId. O campo extra.uid de compatibilidade mantém o UID original do MTP. Os caminhos de anexo mantêm-se com valores opacos e podem apontar para ficheiros locais aos quais um consumidor remoto não pode aceder.

O resumo no terminal identifica os testes instáveis e os testes repetidos. Os relatórios TRX e JUnit mantêm um resultado final por teste em vez de registarem todas as tentativas.

Azure DevOps Relatórios

A extensão de relatório Azure DevOps integra execuções de teste MTP com o Azure Pipelines. Formata erros e avisos para registos de pipeline, adiciona anotações para testes falhados e saltados, cria um resumo de tarefas Markdown e pode agrupar a saída por montagem de teste. A extensão também pode identificar falhas instáveis ou em quarentena, carregar artefactos de teste e transmitir resultados para uma execução de teste Azure DevOps.

Quando aloja o seu código no GitHub mas executa testes em agentes do Azure Pipelines, as anotações de falha podem aparecer diretamente no pull request do GitHub:

Esta extensão requer o pacote NuGet Microsoft.Testing.Extensions.AzureDevOpsReport .

Registo manual

var builder = await TestApplication.CreateBuilderAsync(args);
builder.TestHost.AddAzureDevOpsProvider();

Opções

A extensão deteta automaticamente que está a correr num ambiente de integração contínua (CI) ao verificar a TF_BUILD variável de ambiente.

A partir do MTP 2.4.0, o Azure DevOps Markdown resume os resultados agregados de todos os módulos de teste numa dotnet test invocação. Quando também ativa a cobertura por código, o resumo inclui contagens cobertas e totais, percentagens, resultados de limiar e um indicador quando os dados de cobertura são parciais.

A partir da versão de pré-visualização do MTP 2.5, o resumo apresenta também taxas de sucesso, histórico de testes intermitentes, comparações de duração, ligações de dependência entre testes, diagnósticos de falhas direcionados e uma disposição determinística compacta para execuções multimódulo.

A partir do MTP 2.4, a publicação em direto transfere automaticamente os anexos de ficheiro dos resultados sem êxito para os resultados de testes no Azure DevOps. Os resultados sem êxito incluem resultados falhados, com erro, expirados e cancelados.

Quando um resultado inclui saída padrão ou erro padrão, a extensão pode anexar até 256 KiB de cada um desses fluxos em linha. Cada anexo com backup de ficheiro tem um limite de 16 MiB.

A extensão também envia ficheiros de nível de execução .coverage, .cobertura.xml e .opencover.xml como anexos de cobertura de código. Estes anexos de teste e resultados são separados de --report-azdo-upload-artifacts, que carrega ficheiros selecionados à medida que o Azure Pipelines constrói artefactos.

Para testes repetidos, o Azure DevOps publica as tentativas anteriores como subresultados e anexa, ao subresultado correspondente, os artefactos gerados por cada tentativa. Se a correlação de repetição segura não estiver disponível, a extensão publica um resultado separado em vez de o descartar.

Quando a publicação em direto cria a execução, imprime o URL da execução para que possa acompanhar os resultados antes de esta estar concluída. Também envia pipelineReference e a data de início quando estes são disponibilizados pelo ambiente do pipeline. O separador Testes da build não lista uma execução em curso; indica a execução após a conclusão.

Relatórios do GitHub Actions

O relatório do GitHub Actions emite comandos de fluxo de trabalho nativos do GitHub Actions, para que as execuções de testes proporcionem uma experiência de topo no runner: grupos de registos por assemblagem, anotações de testes falhados e ignorados (apresentadas no separador Annotations do workflow e, quando é possível resolver a localização de origem, no diff Files changed do pull request), um resumo Markdown da tarefa acrescentado ao ficheiro referenciado por GITHUB_STEP_SUMMARY, e avisos sobre testes lentos.

Esta extensão requer a Microsoft. Testing.Extensions.GitHubActionsReport pacote NuGet.

A extensão só ativa quando a execução está no GitHub Actions (a GITHUB_ACTIONS variável de ambiente é true) e o --report-gh switch está definido; caso contrário, não faz nada. Quando está ativa, cada funcionalidade fica ativa por predefinição e pode ser desativada individualmente através da respetiva opção --report-gh-*.

Registo manual

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddGitHubActionsProvider();

Opções

A partir do MTP 2.4.0, o GitHub Actions Markdown resume os resultados agregados de todos os módulos de teste numa dotnet test invocação. Quando também ativar a cobertura do código, selecione coverage ou all para incluir contagens cobertas e totais, percentagens, resultados dos limiares e um indicador caso os dados de cobertura sejam parciais.

Os detalhes das falhas permanecem dentro dos limites definidos para a mensagem, a pilha de execução, a contagem de falhas e o resumo global. Quando o conteúdo ultrapassa um limite, o relatório trunca-o ou condensa-o e indica essa redução no resumo.