Compartilhar via


Revisar e configurar os resultados da cobertura de código no Azure Pipelines

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

A cobertura de código ajuda você a determinar a proporção do código do projeto que está realmente sendo testado, como por testes de unidade. Para aumentar a confiança nas alterações de código e proteger-se efetivamente contra bugs, seus testes devem executar ou cobrir uma grande parte do código.

Ao examinar os resultados da cobertura de código, você pode identificar caminhos de código que os testes não abrangem. Essas informações ajudam a aperfeiçoar a cobertura de testes ao longo do tempo, reduzindo a dívida técnica.

Este artigo mostra como exibir, configurar e solucionar problemas de cobertura de código no Azure Pipelines. Você aprenderá a configurar a cobertura diferida para solicitações de pull, configurar políticas de cobertura e resolver problemas comuns.

Observação

Embora você possa criar código de vários sistemas de controle de versão compatíveis com o Azure Pipelines, o recurso de cobertura de código para solicitações de pull discutido neste artigo está disponível apenas para o Azure Repos.

Formatos, tarefas e artefatos com suporte

Formatos com suporte

O Azure Pipelines pode publicar resultados de cobertura por meio da tarefa Publicar Resultados de Cobertura de Código v2. A tarefa pode exibir os resultados em dois modos de exibição diferentes:

  • Para formatos cobertura, jacoco, clover, gcov, pcov e outros formatos xml, gera uma exibição HTML, contendo mais detalhes do relatório de cobertura de código, e é preferido pela maioria dos clientes.
  • Para .coverage/.cjson/.covx – uma exibição tabular é gerada, contendo menos detalhes do que o modo de exibição HTML.

Artefatos e resultados

Você pode exibir os artefatos de cobertura de código publicados durante o build na guia Resumo no resumo da execução do pipeline.

A captura de tela mostra a guia Resumo com uma execução manual e dois itens publicados.

Além disso, você pode examinar os resultados do relatório de cobertura de código na guia Cobertura de Código :

A captura de tela mostra o conteúdo da guia Cobertura de Código com resumo, métricas e cobertura.

  • Se você publicar a cobertura de código usando os formatos Cobertura ou JaCoCo, o artefato de cobertura de código conterá um arquivo .html que poderá ser exibido offline para análise posterior. Captura de tela mostrando o resumo do relatório HTML.
  • Para .NET e .NET Core, você pode acessar o link para baixar o artefato escolhendo o marco de cobertura de código no resumo do build.
  • O Teste do Visual Studio pode coletar cobertura para aplicativos .NET e .NET Core. Ele produz .coverage arquivos que você pode baixar e usar para análise adicional no Visual Studio. Captura de tela mostrando os resultados da cobertura de código.

Tarefas

Publicar Resultados de Cobertura de Código publica resultados de cobertura de código no Azure Pipelines, que foram produzidos por uma compilação no formato Cobertura ou JaCoCo.

Tarefas internas, como Visual Studio Test, .NET Core, Ant, Maven, Gulp, Grunt e Gradle fornecem a opção de publicar dados de cobertura de código no pipeline.

Considerações do Docker

Para aplicativos que usam o Docker, você pode executar builds e testes dentro do contêiner e gerar resultados de cobertura de código dentro do contêiner. Para publicar os resultados no pipeline, torne os artefatos resultantes disponíveis para a tarefa Publicar Resultados de Cobertura de Código. Para obter referência, consulte um exemplo semelhante para publicar resultados de teste na seção Compilar, testar e publicar resultados com uma seção de arquivo do Docker para Docker.

Considerações importantes

  • Em um pipeline YAML de vários estágios, os resultados da cobertura de código só estão disponíveis após a conclusão de todo o pipeline. Talvez seja necessário separar o estágio de construção em seu próprio pipeline se você quiser examinar os resultados da cobertura de código antes de implantar na produção.
  • A mesclagem de resultados de cobertura de código de várias execuções de teste atualmente funciona apenas para .NET e .NET Core. Não há planos para dar suporte a outros formatos.

Cobertura completa versus cobertura diferda

A cobertura completa mede a cobertura de toda a base de código de um projeto. No contexto de solicitações de pull, os desenvolvedores se concentram nas alterações que estão fazendo e querem saber se as linhas de código específicas que eles adicionaram ou alteraram são abordadas. Este tipo de cobertura é diff coverage.

As configurações de cobertura YAML diferem de um pipeline YAML porque as configurações de cobertura se aplicam ao repositório e são usadas independentemente de qual pipeline compila seu código. Essa separação também significa que, se você usar pipelines de build clássicos baseados em designer, você obterá a verificação do status de cobertura de código para pull requests.

Os indicadores de cobertura aparecem na exibição de arquivos alterados, independentemente de os detalhes do comentário da solicitação de pull estarem ativados ou não.

Configurar a cobertura de diferenciação

Para alterar as configurações padrão da experiência de cobertura de código para solicitações de pull, inclua um arquivo YAML de configuração nomeado azurepipelines-coverage.yml na raiz do repositório. Defina os valores desejados neste arquivo e o Azure DevOps os usará automaticamente na próxima vez que o pipeline for executado.

Você também alterar as seguintes configurações:

A captura de tela mostra as configurações que você pode definir.

Configuração de exemplo

coverage:  
  status:                    # Code coverage status will be posted to pull requests based on targets defined below. 
    comments: on             # Off by default. When on, details about coverage for each file changed will be posted as a pull request comment.  
    diff:                    # Diff coverage is code coverage only for the lines changed in a pull request. 
      target: 60%            # Set this to a desired percentage. Default is 70 percent 

Você pode encontrar mais exemplos com detalhes no repositório de exemplos YAML de cobertura de código.

Status, detalhes e indicadores da cobertura

Quando você configura um pipeline para coletar e publicar a cobertura de código, ele publica um status de cobertura de código quando você cria um pull request (solicitação de pull). Por padrão, o servidor verifica se os testes abrangem pelo menos 70% de linhas alteradas. Você pode alterar o destino do limite de cobertura dif para um valor escolhido modificando o parâmetro de destino mencionado anteriormente.

Captura de tela que mostra falha na verificação de status de cobertura.

A verificação de status calcula a cobertura do diff para todos os arquivos no pull request. Para ver a porcentagem de cada arquivo, habilite Detalhes, conforme descrito na seção anterior. Quando habilitado, o sistema posta os detalhes como um comentário sobre a solicitação de pull.

A captura de tela mostra o resultado falho da verificação de cobertura de diferença.

Na exibição de arquivos alterados de uma solicitação de pull, as linhas alteradas também são anotadas com indicadores de cobertura para mostrar se essas linhas são cobertas.

A captura de tela mostra indicadores de cobertura de alteração de linha de solicitação de pull.

Aplicar a proteção de ramificação mediante uma política de cobertura de código

Por padrão, a verificação de status de cobertura de código em solicitações de pull é consultiva - ela não bloqueia mesclagens com baixa cobertura. Para garantir que as alterações atendam a um limite mínimo de cobertura antes de mesclar, configure uma política de branch que use a verificação de status de cobertura.

O status da cobertura de código postada de um pipeline segue a convenção de nomenclatura {name-of-your-pipeline/codecoverage}.

Observação

  • As políticas de branch no Azure Repos (até mesmo políticas opcionais) impedem que as solicitações de pull sejam concluídas automaticamente se falharem. Esse comportamento não é específico para a política de cobertura de código.
  • A política de cobertura de código não será substituída por Falha se o build falhar.

Guia de Solução de Problemas

Por que vejo DLLs duplicadas na exibição de cobertura da guia Cobertura de Código?

Você pode ver DLLs duplicadas quando o .NET Core e o .NET Framework são usados no pipeline. Espere DLLs duplicadas quando ambas forem usadas, o que é por design, já que o mesmo módulo vem de caminhos diferentes.

Por que não há dados de cobertura na guia Cobertura de Código?

Vários motivos podem causar esse problema:

  • Nenhum teste ou DLLs presentes: se os arquivos não contiverem testes ou DLLs, o valor de cobertura será 0. O Azure DevOps não exibe dados de cobertura de código na guia quando o valor da cobertura é 0. Em vez disso, ele mostra uma mensagem na aba Cobertura de Código explicando por que não há dados de cobertura.

  • XML de cobertura vazia: Quando você utiliza as tarefas de publicação de cobertura de código, se a cobertura .xml fornecida como entrada não contiver nenhuma informação ou tiver zero linhas cobertas, nenhum dado de cobertura aparecerá na aba. Investigue a razão pela qual o arquivo de cobertura .xml (arquivo de entrada) está vazio ou não possui informações.

  • Falhas de build: Se o build falhar, a guia de cobertura de código será exibida com uma mensagem apropriada.

  • Configuração da tarefa VSTest: ao usar a tarefa VSTest, se você não habilitar a verificação de cobertura de código ou se mencionar DLLs incorretas ou caminhos incorretos para testar arquivos no campo Filtro de teste, os dados de cobertura não serão exibidos.

  • Problemas de configuração de build: às vezes, existem vários valores de configuração de build e você não define todos os valores, como BuildFlavour ou BuildPlatform. A interface do usuário mostra apenas valores de configurações de build específicas, razão pela qual outros módulos estão ausentes.

  • Arquivos HTML grandes: se o .html arquivo for maior que 7 MB, o relatório não estará disponível na guia Cobertura de Código. Como solução alternativa, baixe o artefato "Cobertura de Código Report_*" dos artefatos publicados no Resumo.

  • Mensagens de falha: se a guia Cobertura de Código contiver uma mensagem de falha relacionada a um erro específico do usuário, investigue o que disparou essa mensagem de erro.

O que devo fazer se a Verificação de Status de Cobertura de Código nunca for concluída ou falhar?

Para habilitar a verificação de status de cobertura de código, tente adicionar o azurepipelines-coverage.yml arquivo na raiz do repositório. Verifique se o nome do arquivo permanece exatamente o mesmo. Veja um exemplo:

coverage: 
  status: 
    comments: on 
    diff: 
      target: 50% 

Se a verificação de status de cobertura estiver falhando:

  1. Verifique a porcentagem de cobertura de diff. Se for menor que o alvo, tente aumentar o percentual de cobertura da diferença.
  2. Se a construção falhou por algum motivo, essa falha também pode fazer com que a verificação de status da cobertura de código falhe.
  3. Verifique qual tarefa produz os arquivos ou relatórios de cobertura no pipeline. Verifique se a tarefa está carregando corretamente o relatório ou o arquivo de cobertura.
  4. Casos em que os comentários de cobertura diff mostram "Nenhuma alteração executável" ou "Nenhum dado de cobertura de código encontrado" podem ocorrer devido à remoção de linhas, inserções de espaços em branco ou adições de comentários. Esses casos são alterações inexecutáveis e não são significativos, portanto, a cobertura de código não os relata.

Como posso excluir algumas DLLs da cobertura de código?

Para excluir arquivos da cobertura de código, utilize a classe ExcludeFromCodeCoverageAttribute.

Como publicar o resumo da cobertura de código com detalhes adequados mesclando vários arquivos de resumo?

A tarefa Publicar Cobertura de Código V1 não dá suporte a vários arquivos de resumo como entrada. Em vez disso, use a tarefa Publicar Cobertura de Código V2, que dá suporte a vários formatos de arquivo.

Você também pode usar a tarefa Gerador de Relatórios para mesclar todos os .xml arquivos e passar o caminho XML gerado como entrada para a tarefa Publicar Cobertura de Código.

Como faço para que a verificação de cobertura de código seja disparada?

Para arquivos .html, não há suporte para verificações de status de cobertura. Use a tarefa de Verificações de Qualidade de Compilação para conferir os resultados da cobertura de código.

O relatório na guia Cobertura de Código contém números imprecisos

Os dados exibidos na aba são provenientes do arquivo de cobertura. Se você estiver usando tarefas personalizadas para gerar o arquivo de cobertura de código, verifique se há alguma DLL ou arquivo ausente dentro do arquivo.

A política de cobertura de código está paralisada, o que causa isso?

Vários fatores podem causar esse problema:

  • Formato de nome de política de ramificação incorreto: certifique-se de que o nome do pipeline corresponde ao nome da política de ramificação e não contém caracteres extras.

    A captura de tela mostra a aba Políticas e o nome da política de ramificação destacado, para confirmar se corresponde ao nome do pipeline.

  • Usando PublishCodeCoverage V1: a política de cobertura de código fica paralisada e os comentários não são gerados. Em vez disso, use a tarefa PublishCodeCoverage V2.

  • Muitos arquivos em PR: se a PR tiver mais de 100 arquivos, a política de cobertura ficará paralisada.

  • Várias políticas de cobertura: se você configurar várias políticas de cobertura, uma delas ficará paralisada. Configure apenas uma política e exclua a outra política paralisada.

Vejo 0% cobertura diferente para minhas PRs mesmo depois de adicionar testes

Se você adicionar testes para cobrir linhas de código modificadas ou novas em uma PR e ainda vir 0% cobertura diferida:

  1. Verifique se os testes recém-adicionados são executados como parte do build.
  2. Se os testes não forem executados, verifique e atualize a configuração para incluí-los no build, pois a cobertura não poderá ser calculada se os testes não forem executados.

Eu não vejo o comentário de cobertura dif sobre PR mesmo que eu veja o relatório de cobertura sendo publicado

Vários fatores podem causar esse problema:

  • Versão da tarefa: Comentários de cobertura do Diff têm suporte apenas com Publicar Cobertura de Código V2.
  • Nenhuma alteração executável: Os comentários de cobertura de Diff são gerados para arquivos com alterações em código executável. Se a PR tiver apenas atualizações de configuração, o Azure DevOps poderá mostrar a cobertura de código com base em todos os testes executados durante o build, mas pode não haver nenhuma cobertura diferida a ser calculada.
  • Formato de cobertura: se houver alterações de código funcionais e o comentário não for gerado, verifique se o pipeline gera um relatório de cobertura em um dos formatos com suporte mencionados no início deste artigo.

Na guia Cobertura de Código, não vejo o relatório HTML correto

Quando há problemas ao gerar o .html relatório, o sistema volta para uma exibição simplificada.

A captura de tela mostra a guia Cobertura de Código e a lista de módulos e o indicador visual do gráfico de cobertura, que é a exibição simplificada de fallback.

Quais ferramentas de cobertura e formatos de resultado podem ser usados para validar a cobertura de código em solicitações de pull?

Atualmente, você só pode usar formatos de cobertura do Visual Studio Code (.coverage) para validar a cobertura de código para solicitações de pull. Use esse formato se você publicar a cobertura de código usando a tarefa Teste do Visual Studio, o verbo de teste da tarefa .NET Core e a opção TRX da tarefa Publicar Resultados do Teste.

Se vários pipelines forem acionados quando uma solicitação pull for gerada, a cobertura será mesclada entre os pipelines?

Se vários pipelines forem disparados quando uma solicitação de pull for gerada, a cobertura de código não será mesclada. Atualmente, essa funcionalidade foi projetada para um único pipeline que coleta e publica a cobertura de código para solicitações de pull. Se você precisar mesclar dados de cobertura entre pipelines, envie uma solicitação de recurso na Comunidade de desenvolvedores.