Relatórios de cobertura de código separados para testes de unidade e integração ou um relatório para ambos?

Deve haver um relatório de cobertura de código separado para testes de unidade e integração ou um relatório de cobertura de código para ambos?

O pensamento por trás disso é que a cobertura do código nos permite garantir que nosso código tenha sido coberto por testes o máximo possível (o máximo que uma máquina pode agora).

Ter um relatório separado é mais conveniente para nós saber o que não foi coberto por testes de unidade e o que não foi coberto por testes de integração. Mas, dessa forma, não podemos ver a porcentagem total de cobertura.

Acima de tudo, você precisa ter e analisar a cobertura combinada (total). Se você pensar bem, esta é a maneira mais natural de priorizar adequadamente seus riscos e concentrar seu esforço de desenvolvimento de teste.

Cobertura combinada mostra-lhe o código não é coberto por testes em tudo , ou seja, é mais arriscado e precisam ser investigadas em primeiro lugar. Relatórios de cobertura separados não ajudarão aqui, pois eles não permitem descobrir se o código foi testado de alguma forma ou se não foi testado.

A análise de cobertura separada também pode ser útil, mas seria melhor depois que você concluir a análise combinada e, de preferência, também envolveria resultados da análise da cobertura combinada.

O objetivo da análise de cobertura separada difere da combinada. A análise de cobertura separada ajuda a melhorar o design do seu conjunto de testes, em oposição à análise da cobertura combinada, que se destina a decidir sobre os testes a serem desenvolvidos, não importa o quê.

"Oh, essa lacuna não é coberta apenas porque esquecemos de adicionar esse teste simples de unidade (integração) ao nosso conjunto de unidades (integração), vamos adicioná-lo" - a cobertura e a análise separadas são mais úteis aqui, pois uma combinação pode esconder as lacunas que você gostaria de cobrir em particular suíte.

Da perspectiva acima, ainda é desejável ter também resultados da análise de cobertura combinada para analisar casos mais complicados. Pense nisso, com esses resultados, suas decisões de desenvolvimento de teste podem ser mais eficientes devido a informações sobre conjuntos de testes "parceiros".

"Existe uma lacuna aqui, mas desenvolver um teste de unidade (integração) para cobri-la seria realmente complicado, quais são as nossas opções? Vamos verificar a cobertura combinada ... oh, ela já está coberta em outro lugar, ou seja, a cobertura em nossa suíte não é ' criticamente importante ".

Você não menciona sua ferramenta de teste. Muitos possuem funções "combinadas" que permitem agregar os resultados de várias execuções ou suítes. Se você deseja uma métrica de cobertura agregada, explore o recurso de combinação em sua ferramenta de cobertura.

Agora, podemos falar sobre o elefante na sala?

Não tem colher. E não há "porcentagem total de cobertura". Pelo menos, não é simples.

A porcentagem de cobertura é uma métrica prontamente compreendida apresentada para ajudar a entender o escopo, a profundidade e o alcance dos conjuntos de testes. Mas, como qualquer referência simples, é muito fácil tornar-se alvo fixado nesse valor como uma espécie de talismã mágico de "teste completo".

Digamos que você tenha alcançado a glória de "100% de cobertura de teste". Yay! Mas o que isso significa? 100% das linhas de código são testadas, certo? Então, e essa linha?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

"Cobrir" essa linha significa algo - mas não muito, porque há uma variedade de condições que são Trueou Falsecom alguma probabilidade, mas é improvável que você tenha testado todas as combinações dessas condições. Mesmo que essa linha seja coberta uma dúzia de vezes, se uma das condições for relativamente incomum, você não chegou perto de testar todos os resultados reais que podem ocorrer na prática. Para deixar isso mais claro, um exemplo mais sintético:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

Quantas vezes você teria que cobrir essa linha para realmente testá-la exaustivamente? Quantas vezes você precisaria cobri-lo para testá-lo em combinação com todas as outras variáveis ​​do programa (com suas próprias probabilidades, possivelmente igualmente raras)?

Não estou dizendo que as métricas de cobertura são inúteis. Eles são realmente ótimos . Eles se concentram em um dos principais problemas: Qual a extensão do meu sistema de software testado? Eles ajudam a passar de "nós temos alguns testes" para "nós testamos completamente".

Porém, enquanto você trabalha com "pontuações combinadas", a realidade é que sua pontuação normalmente será para cobertura de "declaração de declarações" em vez de cobertura de "condição", "predicado" ou "caminho" . Portanto, seja qual for o número que suas pontuações agregadas lhe fornecerem, é improvável que ele lhe dê uma imagem verdadeira de quanto dos estados e combinações de estados em potencial do seu programa está sendo testado. Enquanto você estiver trabalhando para aumentar sua porcentagem de cobertura, considere também medir sua cobertura de predicado. Isso fornecerá uma visão mais realista - e quase invariavelmente, mais preocupante - da extensibilidade dos testes.