Minha cobertura de testes não faz sentido! : O método do “antes e depois”

Se você chegou até aqui, provavelmente está passando alguma dificuldade com relação à cobertura de testes do seu projeto. Então imagine a seguinte situação:

Você está fazendo uma remoção simples no código do seu projeto. Você faz todas as alterações que deveriam ser feitas, altera os testes para se adequarem aos seus ajudes… talvez até tenha escrito testes novos. Os testes passam, um-a-um, até que um evento fatídico toma conta do seu PR: a cobertura geral de testes foi REDUZIDA!?!

Mas… se eu removi trechos de código, a cobertura não deveria ter sido AUMENTADA? Se eu reduzi a amostragem e mantive os testes, não deveria o percentual de cobertura ter SUBIDO?!? Minha cobertura de testes não faz sentido!!

Este é mais um daqueles momentos em que a matemática parece não estar “matematicando”. E para nós, programadores, que temos a lógica como base da profissão, pode ser algo de tirar o sono.

Se você já passou por isso — como eu passei recentemente — pode ser que tenha quebrado a cabeça por horas tentando descobrir o que aconteceu, qual mudança afetou a cobertura total e qual dos diversos arquivos “atacar” para aumentar a cobertura.

O que eu não fazia ideia quando passei por isso é que existe uma metodologia muito simples para resolver o problema de coverages que “não fazem sentido”. Ou pelo menos para te dar dados reais e uma base matemática para você tirar suas próprias conclusões e tomar decisões.

A lógica é simples e consiste em comparar a cobertura antes e depois das mudanças feitas. Ou seja, os dados de cobertura geral da sua branch com os da branch main/master do projeto (Iremos utilizar JavaScript e Jest como exemplo).

Por que disso?

Ora, o que queremos verificar aqui é se mantemos ou não os padrões de garantia da qualidade de código. Afinal de contas, ninguém quer ser o responsável por uma entrega que prejudica a qualidade do produto, certo?

Isso posto, ao comparar os dados da cobertura nesse método de antes/depois é possível verificar:

1. Qual arquivo teve a cobertura reduzida e quais as linhas impactadas.
2. Ou se, por pura questão de matemática, as mudanças na amostragem geral de código refletiram no percentual coberto.

No caso um, é preciso retornar a cobertura à taxa anterior, uma vez que os padrões de garantia de qualidade do código não estão sendo mantidos.

Já no caso dois, é perfeitamente aceitável mantê-la abaixo dos parâmetros anteriores, pois fica provado matematicamente que o padrão de garantia de qualidade está sendo mantido. E, confia em mim, não tem argumento melhor do que algo provado em dados.

Ta, mas pera aí… meu projeto tem mais de 200 arquivos… cada um com a sua coverage própria. Comparar as taxas manualmente seria uma tarefa enorme, monótona e com risco de erro!

Eu tive esse mesmo pensamento quando ouvi esse método pela primeira vez… Mas, eu sou programadora, e como todo programador, pensei: Porque gastar duas horas em uma tarefa manual se eu posso automatizá-la em cinco horas e nunca mais ter que fazê-la, certo?

Para os que não estão familiarizados com Jest, ao calcular a cobertura de testes ele gera uma tabelinha para você no próprio terminal, mais ou menos como a mostrada na figura abaixo:

O que pouco se fala sobre é sobre o relatório em HTML infinitamente mais completo que é gerado e salvo dentro da pasta do projeto. Geralmente vai estar dentro de uma pasta coverage > lcov-report e, por padrão, o arquivo gerado chama-se index.html. É só clicar que ele abre no seu navegador padrão e é ele que vamos usar no método. Para fins de demonstração, esse arquivo se parece com o da imagem abaixo:

Eu imagino que a essa altura do artigo você já está pensando no que eu estou pensando…

Bom, se eu tenho duas tabelas com as mesmas colunas, mas com dados diferentes, eu posso abri-las no Excel e escrever fórmulas para compará-las automaticamente: e foi exatamente essa a solução que desenvolvemos no meu time na RD Station — Cá, entre nós, algo que foi muito mais divertido do que ficar olhando linha-a-linha de um arquivo HTML.

Montamos um modelo de planilha que compara coluna-a-coluna e que sinaliza as diferenças entre o “antes” e o “depois” de uma maneira automática e visual. Basta copiar e colar os dados da planilha de coverage.

O melhor de tudo é que agora você, leitor, pode usá-la também. Basta fazer uma cópia desse arquivo aqui e seguir as instruções dentro dele.

A planilha te mostra em quais arquivos houve diferença na cobertura de testes na aba “Comparação” e na aba “Cálculo de Coverage” te mostra o impacto numérico disso no cálculo de porcentagem.

A vantagem é que, se for preciso agir, você já saberá qual o arquivo. Então basta abrir o index.html correspondente à sua branch atual, clicar no arquivo indicado como “Diferente” pela planilha e ele te mostrará quais as linhas podem ser melhoradas.

Para fins de exemplo, deixei duas linhas com os Statements diferentes na tabela “Comparação”, linhas 5 e 8:

Como você pode perceber, ambas as linhas foram sinalizadas como “Diferente”, pela tabela. Pode-se verificar que uma delas foi de 13/14 para 10/14, e a outra de 6/6 para 4/4.

Ou seja, no primeiro exemplo, como foi mantido o número de funções totais (14), mas reduzido o número de funções cobertas de 13 para 10, conclui-se que aqui houve perda da garantia da qualidade — o que exige ação e a escrita de mais testes neste arquivo.

Já no segundo exemplo, o número total de Statements foi reduzido juntamente com o número de funções cobertas. Por sua vez, indicando que não houve perda na garantia de qualidade, apenas uma redução da amostragem.

Essa mesma análise dos últimos dois parágrafos é feita na tab “Cálculo de Coverage” e entregue de maneira visual para cada usuário se houve apenas uma redução da amostragem, ou se houve perda de garantia de qualidade. Olha que legal:

Como outro exemplo, se olharmos para as Branches da tabela “Comparação”, você pode perceber que esta também é sinalizada como “Diferente”, pois foi de 3/3 para 2/2:

Da mesma forma, a tab “Cálculo de Coverage” faz a análise e sinaliza a perda como “Redução da amostragem”:

Dito isso, o desfecho da minha história — e que eu espero que seja o da sua também — foi o seguinte: Descobrimos que os 0.2% de diferença na cobertura de testes acontecia porque a cobertura de um dos arquivos ia de 6/6 para 4/4, mantendo os 100% de cobertura, mas reduzindo a amostragem geral.

Ou seja, como o que foi reduzido foi apenas o número de funções existentes, ficou nítida e sinalizada a “Redução da amostragem”, me dando a justificativa necessária para poder subir um PR com redução do coverage geral.

Só sei que eu não tive que escrever mais nenhum teste automatizado naquele dia e, para mim, esse é um final mais do que feliz.

Me conta nos comentários como você resolveria esse problema e se você tem alguma sugestão de melhoria pra planilha :)

#coverage #calculodecoverage #coberturadetestes #testesautomatizados #qualidadedecodigo #qa #jest #automatedtests