Code Coverage e a ilusão de qualidade

A crescente adoção de testes automatizados como uma prática corriqueira dentro das equipes de desenvolvimento trouxe com ela a métrica chamada de code coverage, que indica o quanto (%) seu código de produção está coberto por testes.

Em seguida, as diversas ferramentas que possibilitaram automatizar as práticas de CI/CD também permitiram adicionar à pipeline de build/deploy um passo para o cálculo do code coverage e a publicação do resultado da análise em ferramentas como o SonarQube e o Coveralls.io.

Com isso, ganhamos agilidade (análise de code coverage executada automaticamente a cada build) e visibilidade (resultado publicado num formato organizado, exibindo o % de cobertura em nível de pacote, classe e método).

Como a “cereja  do bolo”, ainda conseguimos barrar a pipeline em determinada etapa, caso o percentual de coverage esteja abaixo de um limite considerado aceitável.

Soa muito bem, não? Agora, o quão isso tudo está perto de garantir qualidade do software? E o que acontece quando a equipe programa cegamente para atingir o limite mínimo estipulado na pipeline?

CODE COVERAGE E QUALIDADE

Um percentual de, digamos, 90% de code coverage é um belo número. O ponto é que este número só significa que, bem, você tem 90% de código coberto por testes. Isoladamente, este número não indica o quão BEM testado está o código.

Um olhar atento em uma suíte de testes e é bem provável que encontremos testes cujas asserções não garantem muita coisa, como:

• testes de API que checam o status code do response HTTP, mas desprezam o body;
• testes que apenas verificam que o retorno do método da SUT é diferente de nulo ou uma lista não vazia;

Testes assim somente satisfazem a meta de coverage, mas não irão ajudar muito quando um bug for introduzido no código.

Outro fator que o code coverage não ajuda é quanto à manutenibilidade do código de teste. Não é raro encontrarmos suítes de testes de baixa qualidade, apresentando poucas ou nenhuma destas características fundamentais.

Desta forma, a suíte de testes, com seus belos 90% de code coverage, acaba sendo um fardo grande para a equipe, prejudicando a produtividade e, consequentemente, gerando altos custos de manutenção.

Por fim, o percentual de coverage ignora a estratégia de testes adotada. Em outras palavras, você pode chegar a 100% de cobertura escrevendo 1000 testes end-to-end e nenhum teste de unidade, o que, além de menos assertivo quanto à localização do problema quando um teste falha, é muito mais custoso em termos de desenvolvimento e execução da suíte.

OBSESSÃO PELO NÚMERO

Quando a equipe trabalha cegamente para atingir o limite esperado (ou imposto?) de coverage, principalmente quando ele é uma barreira para seguir na pipeline de deploy,  ela negligencia todos os pontos mencionados anteriormente.

Sendo assim, a equipe acaba não evoluindo tecnicamente, no que se refere a boas práticas de testes, já que, provavelmente, sequer entende os benefícios dos mesmos.

CONCLUINDO

Use a métrica de code coverage, na melhor das hipóteses, como um indicador de que as coisas estão indo mal e não de que estão indo bem. Isto é, use o percentual muito baixo como um grande alerta de que o código está sendo pouco testado e identifique a causa raiz. Não existe um número mágico para indicar um “percentual muito baixo”. Apenas atente-se a quedas do tipo “de 70% para 50%” e investigue.

Não fique cegamente correndo atrás de um número. Preocupe-se mais com a qualidade dos testes que estão sendo escritos:  se eles cobrem os cenários principais, se suas asserções realmente testam o que deviam testar, se não há mais de 1 teste validando a mesma coisa, se eles são fáceis de manter, etc. Aqui mesmo no blog, há uma porção de artigos sobre o assunto.

E você? Tem usado essa métrica no dia-a-dia? De que forma? Comente-aí!

Até o próximo!