A métrica de cobertura de código virou o novo “peso na balança” de muitas equipes de desenvolvimento. Ferramentas como SonarQube, Coveralls e Codecov — facilmente plugadas em pipelines CI/CD — barram o merge de qualquer PR que fique abaixo da mítica marca dos 80 %. Mas… e se eu disser que tornar seu código mais limpo, enxuto e reutilizável pode fazer exatamente esse número despencar? Foi isso que um experimento detalhado no Stack Overflow Blog demonstrou, chacoalhando a confiança cega nessa estatística.
De onde veio o tal “80 %” e por que ele engana
Muita gente cita o Princípio de Pareto (80 / 20) para justificar o limite. Só que a leitura está, no mínimo, capenga. Pareto diz que 80 % dos efeitos vêm de 20 % das causas, não que “tudo abaixo de 80 % é código ruim”. Aplicar o mesmo corte a cada arquivo — da rotina crítica de criptografia até o script que troca o tema para modo escuro — é tratar tudo como igualmente importante, ignorando risco, impacto financeiro e custo de manutenção.
DRY vs. WET: quando escrever menos linhas atrapalha a métrica
Seguir o princípio Don’t Repeat Yourself (DRY) normalmente é uma vitória: você reduz duplicação, facilita a manutenção e diminui bugs. Porém, ao extrair blocos repetidos para uma função compartilhada, a contagem total de linhas cai. Se os testes não crescerem na mesma proporção, a porcentagem de cobertura inevitavelmente desce. No exemplo do post, refatorar de 100 para 90 linhas — sem tocar nos testes — derrubou a cobertura de 80 % para 77,8 %, bloqueando o merge.
Cobertura alta ≠ testes bons
Martin Fowler já alertava: é possível ter 100 % de cobertura com asserts vazios. No experimento, uma função JavaScript escrita em apenas uma linha (return x || y || z;) manteve 100 % de cobertura mesmo após desativar 75 % dos testes. Versões mais verbosas (if-else ou switch) mostraram quedas claras, expondo o buraco. Moral da história? Quanto mais conciso o código, mais fácil inflar a métrica sem necessariamente validar todos os caminhos.
Quanto custa testar — e quando vale a pena automatizar
Automação não é grátis. Se escrever um teste leva quatro horas e a validação manual consome 20 minutos, você só “empata” depois da 12.ª execução. Para casos extremos — um teste que levaria 16 h para automatizar e 5 min para revisar à mão — o ROI só chega após 192 implantações. Nem toda feature merece o mesmo investimento: falhar num gateway de pagamento é inaceitável; falhar no dark mode, tolerável.
Como extrair valor real da cobertura de código
- Pese risco e impacto: defina limiares diferentes para diretórios ou módulos críticos. Alguns arquivos merecem 95 %; outros, 50 % é mais do que suficiente.
- Combine métricas: além de cobertura, monitore bugs em produção, tempo médio de correção (MTTR) e satisfação do usuário.
- Revise a arquitetura: código mais explícito (por exemplo, evitar “one-liners” complexas) facilita tanto a leitura humana quanto a identificação de lacunas pelos relatórios.
- Use testes manuais, end-to-end e mocks quando eles entregarem melhor custo-benefício.
E o que isso significa para o seu dia a dia de dev?
Se a chuva de alertas “coverage failed” está travando seus PRs, talvez seja hora de recalibrar a régua — e não de adiar aquela refatoração importante. Ferramentas são aliadas, não juízes supremos. Otimizar o que importa libera tempo para inovar, seja lapidando a API do seu app ou escolhendo periféricos que elevem sua produtividade.
Imagem: Internet
Aliás, fica uma dica rápida para quem passa horas escrevendo testes: um teclado mecânico silencioso com switches lineares, como o Keychron K8 Pro, reduz fadiga e acelera a digitação (disponível na Amazon). Complementar com um mouse vertical ergonômico também ajuda a evitar dores no punho durante maratonas de QA.
No fim das contas, melhorar o código e a experiência de quem o escreve pode — e deve — caminhar junto. Só não deixe que um número isolado dite todo o rumo do seu projeto.
Com informações de Stack Overflow Blog
