Os Riscos e Limitações de Confiar Exclusivamente na Porcentagem de Cobertura de Código
Testes valiosos e eficazes estão preocupados com outros aspectos, a cobertura de código é consequência de testes de qualidade, planejados e abrangentes, focados no comportamento observável do recurso.
É um equívoco comum entre alguns desenvolvedores que a refatoração do código, que resulta em um declínio no número total de linhas, inevitavelmente levará a uma melhoria automática na qualidade dos nossos testes e relatórios. No entanto, este raciocínio carece de fundamento lógico e não oferece benefícios reais para a qualidade do código ou a eficácia dos testes.
É imperativo entender que a cobertura do código é uma métrica relativa e não deve ser interpretada isoladamente. Reduzir o número de linhas de código não garante necessariamente testes mais robustos ou mais completos. A refatoração deve ser orientada para a melhoria da legibilidade, eficiência e manutenibilidade do código, e não apenas para a redução do número de linhas.
Para ilustrar como uma abordagem míope focada apenas na métrica de cobertura do código pode ser enganosa, consideremos o seguinte exemplo:
O código acima pode ser refatorado, mas observe que nada mudará nos testes unitários, ou seja, o comportamento permanecerá o mesmo. Veja como o relatório gerado com a porcentagem da linha será afetado após a refatoração:
ANTES DA REFATORAÇÃO:
DEPOIS DA REFATORAÇÃO:
Código refatorado:
O percentual de cobertura aumentou (Line Coverage das duas imagens), era 46% mas agora estamos em 80%, isso significa que temos uma evolução ou melhoria nos cenários de testes? Não!
Note que apenas reduzimos as linhas de código, mas os comportamentos e as ramificações importantes não são cobertos pelos testes! Não escrevemos nenhum outro cenário de teste, o número de linhas cobertas mudou apenas porque após a refatoração o número de linhas diminuiu!
Se você observar as imagens antes e depois, a porcentagem de cobertura da ramificação (caminhos que o algoritmo pode seguir) permanece a mesma, mesmo com a refatoração. E esse é um dos grandes problemas na hora de trabalhar com cobertura de código, muitas vezes se agirmos sem pensar ou analisar bem, acabamos sendo enganados!
Pode ser muito fácil manipular os números de cobertura. Quanto mais compacto for o seu código, melhor será a métrica de cobertura do teste, pois se considera apenas os números brutos das linhas. É por isso que uma análise cuidadosa é necessária por parte de desenvolvedores e testadores de software, novamente zelando pela qualidade dos testes escritos. O que isso prova? A cobertura do código por linha, ou seja, esse percentual gerado no relatório, não tem relação com a qualidade.
Só porque seu código está 100% coberto não significa que seus testes refletem qualidade. Tudo o que acabamos de ver reforça ainda mais que esse relatório é apenas uma ferramenta a ser utilizada para que possamos criar testes eficazes e de qualidade, é uma ferramenta que nos ajuda, mas não podemos depender totalmente dela sem analisar minuciosamente todos as entradas e saídas.
Além disso, um teste precisa ter muitos atributos importantes para ser considerado um teste de qualidade, por exemplo, precisa ser legível, organizado, fácil de entender, sem dezenas de asserções e focado principalmente em testar comportamentos da funcionalidade. Então, acabamos de responder à pergunta: a cobertura do código indica qualidade?
Não é indicativo de qualidade! Testes valiosos e eficazes estão preocupados em outros aspectos, cobertura de código é uma consequência de testes de qualidade, planejados e abrangentes focados no comportamento observável do recurso!
📍Os perigos de confiar totalmente nas métricas de cobertura de código
Foco em métricas quantitativas em detrimento da qualidade: m=Muita ênfase na porcentagem de cobertura de código pode levar a equipe a focar apenas em métricas quantitativas, desconsiderando aspectos qualitativos importantes da qualidade do software. Isso pode resultar em testes ineficientes e na falta de identificação de problemas potenciais.
Negligenciar aspectos importantes do teste: Ao focar apenas na cobertura do código, a equipe pode negligenciar outros aspectos importantes do teste, como a qualidade e a relevância dos casos de teste, o que pode resultar em testes mal projetados ou irrelevantes que não contribuem para a melhoria real de qualidade de software.
Falsa sensação de segurança: Confiar totalmente no percentual de cobertura do código pode levar a uma falsa sensação de segurança, fazendo com que a equipe acredite que o software está bem testado e livre de defeitos, mesmo quando há problemas de qualidade nos testes ou casos de uso que não são cobertos.
Ignorar áreas de alto risco ou complexidade: A cobertura do código não leva em consideração a complexidade do código e as interações entre os diferentes componentes do sistema. Isso significa que áreas de alto risco ou complexas podem não receber a devida atenção, mesmo que o percentual de cobertura seja alto.
Com base na lista acima, fica claro quais problemas podemos encontrar no software e até mesmo durante o desenvolvimento se confiarmos cegamente em porcentagens e métricas. É importante reforçar esses riscos com a equipe de engenharia, gerentes de software e qualquer outra pessoa envolvida. Afinal, queremos um produto realmente confiável!
📍Como podemos usar as métricas de cobertura de código a nosso favor?
Como podemos usar essa ferramenta a nosso favor sem cair nas armadilhas da cobertura de linha? Podemos listar algumas sugestões, com base no que outros especialistas compartilham e também com base em algumas experiências de projetos em que trabalhei:
Use essa ferramenta em áreas do código que são mais complexas e críticas para o tipo de negócio em que você está trabalhando.
Se a equipe descobrir que um arquivo tem cobertura zero ou uma porcentagem muito baixa e número de ramificações que não foram cobertas, é útil escrever cenários de teste para comportamento.
Reforce a importância de testar ramificações de código! As ramificações indicam os caminhos que um algoritmo pode seguir para atingir seu objetivo. Portanto, se o seu código contém muitas estruturas
if/else, sempre vale a pena observar como os testes são construído s em cima dessas ramificações e se elas existem.Preste atenção no relatório de cobertura, mas nunca assuma que os testes foram escritos com qualidade e cobrem todos os comportamentos da funcionalidade, apenas com base no relatório. Como vimos, 100% de cobertura de código não tem relação com a qualidade do teste.
Não adianta estabelecer altas porcentagens no projeto e mesmo nos arquivos se a qualidade na escrita dos testes e cenários continuar insuficiente ou inadequada.
As ferramentas que geram relatórios de cobertura podem mostrar a complexidade ciclomático do código e isso pode ajudá-lo a indicar se você deve ou não refatorar a classe ou os métodos. Então isso é um fator muito positivo. Sempre verifique se a refatoração é possível para melhorar a legibilidade do seu código.
Revisões de código e colaboração, métricas de cobertura de código podem fornecer informações úteis para revisões de código, ajudando os revisores a se concentrarem em áreas menos testadas e a identificar riscos potenciais.
Revise cuidadosamente os relatórios e porcentagens mostrados, nunca ignore outros cenários de teste!
📍 Conclusão
É importante destacar os problemas de confiar totalmente nas porcentagens de cobertura de código como única métrica para avaliar a qualidade dos testes e do software em geral. Embora a cobertura de código seja uma ferramenta valiosa para identificar áreas que precisam de mais atenção nos testes, é fundamental entender suas limitações e não usá-la como único indicador.
Um dos principais problemas em confiar exclusivamente na cobertura de código é a falsa sensação de segurança que pode ser gerada. Um alto percentual de abrangência pode levar a equipe a acreditar que o software está bem testado e livre de defeitos. Não queremos ser enganados!
Outro problema é a tendência das equipes focarem apenas em aumentar os percentuais de cobertura, negligenciando outros aspectos importantes do teste, como a qualidade e a relevância dos casos de teste. Testes mal elaborados ou irrelevantes podem aumentar a cobertura, mas não contribuem para uma melhoria real na qualidade do software.
Vimos claramente que essa métrica pode ser manipulada. Fique alerta! 🚨 Evite ser surpreendido. Escreva testes realmente valiosos e use essa ferramenta a seu favor!
Espero que este post tenha ajudado você, se você gostou, por favor, compartilhe com outras pessoas! Até o próximo post! 😉😄
Livros que considero essenciais para todos ✅:
Effective Software Testing: A Developer's Guide - by Mauricio Aniche
Unit Testing Principles, Practices, and Patterns - by Vladimir Khorikov