Cobertura de código com o Bazel

Informar um problema Mostrar fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

O Bazel inclui um subcomando coverage para produzir cobertura de código relatórios sobre repositórios que podem ser testados com bazel coverage. Valor devido às idiossincrasias dos vários ecossistemas linguísticos, isso não é sempre trivial para fazer isso funcionar para um determinado projeto.

Esta página documenta o processo geral para criar e visualizar relatórios de cobertura e também traz algumas observações específicas por idioma para linguagens com configuração bem conhecida. É melhor ler primeiro lendo a seção geral e depois lendo sobre os requisitos de uma linguagem específica. Observe também o seção de execução remota, que requer algumas considerações adicionais.

Embora muitas personalizações sejam possíveis, este documento se concentra em produzem e consomem relatórios do lcov, que atualmente a rota mais aceita.

Como criar um relatório de cobertura

Preparação

O fluxo de trabalho básico para criar relatórios de cobertura exige o seguintes:

  • Um repositório básico com destinos de teste
  • Um conjunto de ferramentas com as ferramentas de cobertura de código específicas da linguagem instaladas
  • Uma "instrumentação" correta configuração

As duas primeiras são específicas da linguagem e, na maioria, diretas, No entanto, a última pode ser mais difícil para projetos complexos.

"Instrumentação" nesse caso se refere às ferramentas de cobertura que estão usada para um alvo específico. O Bazel permite ativar esse recurso subconjunto específico de arquivos usando --instrumentation_filter que especifica um filtro para destinos que são testados com o com a instrumentação ativada. Para ativar a instrumentação para testes, o --instrument_test_targets é obrigatória.

Por padrão, o Bazel tenta corresponder aos pacotes de destino e imprime o filtro relevante como uma mensagem INFO.

Cobertura em execução

Para gerar um relatório de cobertura, use bazel coverage --combined_report=lcov [target]. O comando para o alvo, gerando relatórios de cobertura no formato lcov para cada arquivo.

Depois de terminar, Bazel realiza uma ação que coleta todo o e os mescla em um só arquivo, que é criado em $(bazel info output_path)/_coverage/_coverage_report.dat.

Os relatórios de cobertura também serão gerados se os testes falharem. No entanto, observe que Isso não se estende aos testes com falha - apenas os testes aprovados são relatadas.

Visualização da cobertura

O relatório de cobertura só é gerado em lcov não legível. . A partir disso, podemos usar o utilitário genhtml (parte do lcov projeto) para produzir um relatório que pode ser visualizado em um navegador:

genhtml --output genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat"

Observe que o genhtml também lê o código-fonte para anotar informações ausentes. nos arquivos. Para que isso funcione, espera-se que genhtml é executado na raiz do projeto Bazel.

Para ver o resultado, basta abrir o arquivo index.html produzido no genhtml em qualquer navegador da Web.

Para mais ajuda e informações sobre a ferramenta genhtml ou as lcov, consulte o projeto lcov (em inglês).

Execução remota

No momento, a execução com a execução de teste remoto tem algumas ressalvas:

  • Ainda não é possível executar remotamente a ação de combinação de relatórios. Isso é porque ele não considera os arquivos de saída de cobertura como parte gráfico (consulte este problema) e, portanto, não as tratam corretamente como entradas para a ação de combinação. Para uma solução alternativa, use --strategy=CoverageReport=local.
    • Observação: pode ser necessário especificar algo como --strategy=CoverageReport=local,remote, se o Bazel estiver definido para testar local,remote, devido à forma como o Bazel resolve estratégias.
  • Também não é possível usar --remote_download_minimal e sinalizações semelhantes como consequência da primeira.
  • No momento, o Bazel não cria informações de cobertura se os testes já foram armazenados em cache. Para contornar isso, --nocache_test_results pode ser definido especificamente para execuções de cobertura. embora isso tenha um alto custo em termos de tempo de teste.
  • --experimental_split_coverage_postprocessing e --experimental_fetch_all_coverage_outputs
    • Normalmente, a cobertura é executada como parte da ação de teste e, portanto, Por padrão, não recebemos toda a cobertura de volta como saídas do controle a execução por padrão. Essas sinalizações substituem o padrão e obtêm dos dados de cobertura. Consulte este problema para saber mais detalhes.

Configuração específica da linguagem

Java

O Java deve funcionar pronto para uso com a configuração padrão. O bazel Datasets contêm tudo o que é necessário para a execução remota, inclusive do JUnit.

Python

Consulte os documentos de cobertura do rules_python para saber as etapas adicionais necessárias para ativar o suporte à cobertura no Python.