O problema não está em uma build vermelha por si só, mas em saber se ela foi causada por uma nova regressão, por um teste intermitente ou por uma falha do host de testes que removeu as evidências necessárias para a investigação. O .NET Blog explica como o Microsoft.Testing.Platform, ou MTP, pode tornar os relatórios de testes mais úteis para desenvolvedores, revisores e ferramentas de integração contínua, em vez de simplesmente exibir uma longa lista de logs.
Estas práticas destinam-se a equipes que usam GitHub Actions ou Azure DevOps e querem que as informações sobre falhas cheguem ao ponto de tomada de decisão dentro do pull request. A plataforma também permite produzir mais de um formato de relatório a partir de uma única execução e fornecer saídas estruturadas que programas, painéis e ferramentas de desenvolvimento podem consumir de forma consistente.
Use o histórico da build para distinguir regressões de falhas intermitentes
O Azure DevOps já exibe evidências de testes na guia Tests, mas passar uma janela histórica ao repórter adiciona contexto a cada falha. Ao usar a opção --report-azdo-flaky-history 14, a plataforma consulta o histórico do pipeline dos últimos 14 dias e então distingue o teste que falhou de forma intermitente de um teste sem histórico semelhante.
O teste intermitente pode aparecer com o rótulo [flaky: failed 3/20 in last 14d], enquanto a falha sem esse histórico recebe o rótulo [REGRESSION]. Isso ajuda o revisor a começar a investigação pelo caminho adequado: uma falha sem histórico exige atenção imediata como possível regressão, enquanto uma falha recorrente começa a partir de seu histórico conhecido.
Se a equipe quiser alterar esse comportamento da integração contínua, há a opção --report-azdo-demote-known-flaky, que transforma falhas conhecidas como intermitentes em avisos, mantendo as regressões como erros. No entanto, a fonte enfatiza que a decisão deve ser explícita: queremos usar o histórico apenas para orientar o revisor ou queremos que ele altere automaticamente a gravidade da falha? No pipeline testfx, os comentários históricos foram usados mantendo todos os estados de falha como bloqueadores da build.
O mesmo histórico é usado para detectar testes lentos por meio de --report-azdo-slow-test-history. A opção compara cada teste com seu desempenho anterior, usando um multiplicador configurável e um número mínimo de execuções, para que uma única execução a frio não gere um alerta impreciso.
Preserve as evidências quando o host de testes falhar
Os resultados no formato TRX eram serializados no fim da execução, portanto uma falha grave podia causar a perda de todo o relatório. Agora, os resultados são gravados no disco enquanto são produzidos e, em conjunto com a extensão de despejo de falhas, o relatório parcial pode ser finalizado quando o host parar:
dotnet test --report-trx --crashdump
Isso produz um arquivo TRX válido que inclui todos os testes concluídos, além de uma lista dos testes que estavam em execução no momento da falha. A extensão também grava um arquivo com a extensão .crash.sequence.log, que registra o início e o fim de cada teste, ajudando a identificar o teste que começou mas não terminou, mesmo quando vários testes são executados em paralelo.
Os anexos também são processados. Despejos de falhas, comentários de parada e arquivos de extensões de teste não são mais silenciosamente descartados no .NET Framework quando o caminho excede o limite Windows MAX_PATH. Se não for possível copiar um anexo, isso aparece no console, em vez de ficar mencionado apenas no arquivo TRX. O resultado é que uma execução incompleta aparece claramente como incompleta e não como um relatório verde que oculta evidências ausentes.
Escolha o formato do relatório de acordo com o consumidor
Uma única execução pode ativar vários formatos sem uma etapa de conversão separada. O formato TRX é adequado às ferramentas .NET, enquanto o HTML é apropriado para inspeção direta, e JUnit XML e CTRF JSON são úteis para painéis e automação entre tecnologias. O CTRF oferece um esquema JSON comum para reunir resultados de .NET com resultados de outras linguagens.
Os sistemas de integração contínua leem os formatos TRX e JUnit nas visualizações de resultados, enquanto HTML e CTRF aparecem como arquivos que podem ser baixados ou usados em painéis. No Azure DevOps, a opção --report-azdo-upload-artifacts files pode carregar automaticamente arquivos de evidência dos resultados. Os arquivos também devem ser nomeados usando a opção --report-<format>-filename e espaços reservados como {asm} e {tfm}, para que os resultados não entrem em conflito em projetos direcionados a vários frameworks de runtime.
Torne as saídas estáveis e automatizáveis
A opção --list-tests json fornece um documento com esquema versionado que descreve os testes descobertos e seus locais de origem. Isso constitui uma entrada estável para seleção de testes, análise do impacto das alterações e integração com ambientes de desenvolvimento, em vez de analisar o texto do console, que pode mudar entre versões.
As saídas do MTP se adaptam a ambientes de agentes e modelos de linguagem: ocultam o banner, os caracteres ANSI e a animação de progresso e, por padrão, exibem stdout e stderr apenas para os testes falhos. O comportamento pode ser controlado por NO_COLOR e pelas opções --ansi e --progress.
Fixe a política de relatórios e verifique a compatibilidade
O artigo recomenda experimentar o MTP 2.3 ou uma versão mais recente em um único projeto de teste e, em seguida, ativar --report-gh no GitHub Actions ou --report-azdo no Azure DevOps. Depois de escolher a política, as configurações são salvas no arquivo testconfig.json dentro do repositório, para que as execuções locais e as execuções de CI produzam os mesmos relatórios. Também é possível usar Directory.Build.props para aplicar configurações uniformes a todos os projetos de teste ou usar o perfil AllMicrosoft para ativar o conjunto estável de extensões, mantendo JUnit e CTRF opcionais.
As equipes que não usam MSTest.Sdk devem verificar se as versões dos pacotes dos repórteres correspondem à versão do MTP visada pelo framework de testes. O suporte ao MTP 2.x chega a MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 e às versões de pré-visualização de xunit.v3 4.0. Além disso, a solução não oferece suporte à combinação de projetos MTP e VSTest; portanto, a participação na execução do MTP deve ser configurada no nível do repositório.
As opções de histórico do Azure DevOps exigem o token SYSTEM_ACCESSTOKEN: $(System.AccessToken). Sem ele, a execução continua, mas ignora os comentários históricos. Nos pipelines atuais, as tarefas de publicação de resultados de testes e de publicação de arquivos podem ser substituídas pelas opções correspondentes do MTP, mas a publicação da cobertura de código não é substituída; portanto, é necessário manter PublishCodeCoverageResults@2. Também não se deve ativar a publicação direta junto com PublishTestResults@2, pois isso cria duas execuções de teste separadas para a mesma build.