Cobertura de código: a métrica que mais mente justo quando você mais confia nela

Uma equipe comemora ter alcançado 85% de cobertura. No painel, a barra fica verde e todos respiram aliviados. Duas semanas depois, um bug elementar chega à produção: uma subtração que deveria validar um saldo devolvia o sinal trocado. O estranho não é que o bug existisse. O estranho é que a linha com o erro estava coberta. Os testes a executaram. E, mesmo assim, ninguém a verificou.

A resposta curta para por que isso acontece: a cobertura mede qual código foi executado durante os testes, não qual comportamento foi comprovado. São coisas diferentes, e confundi-las é o erro mais caro e mais comum na gestão de qualidade. A cobertura é um velocímetro que diz a que velocidade você passou por cada trecho do caminho, mas não se você estava olhando para a estrada.

01 · o que medeExecutar uma linha não é o mesmo que testá-la

A cobertura de código é uma medida de quanto do seu código-fonte foi percorrido enquanto rodava um conjunto de testes. Um instrumento observa a execução e anota quais linhas, quais ramos e quais condições foram ativados. No final, divide o percorrido pelo total e entrega um percentual. É só isso que ele faz: contar visitas.

O problema aparece no salto que a mente faz sozinha. Ver "85% de cobertura" e ler "85% testado" é uma miragem tão natural que quase ninguém percebe. Um teste pode chamar uma função, fazer com que cada uma de suas linhas seja executada, e não comprovar nada do resultado. Se não há uma asserção dizendo "o saldo deve ser 100", a linha conta como coberta mesmo que devolva lixo.

A cobertura conta linhas visitadas. A qualidade depende de comportamentos verificados. Não é a mesma coisa.

Há vários tipos, e ordená-los importa porque não exigem o mesmo. A cobertura de linhas pergunta se cada linha foi executada. A cobertura de ramos pergunta se cada bifurcação (cada if) foi tomada por ambos os caminhos, o verdadeiro e o falso. A cobertura de condições desce ainda mais: dentro de um if com várias condições unidas por and ou or, pergunta se cada condição individual foi verdadeira e falsa alguma vez. Um 100% de linhas pode conviver com um 50% de ramos: basta nunca ter testado o caminho do else.

02 · a armadilhaQuando o número sobe e a qualidade não se move

A maior armadilha não é técnica, é humana, e tem nome. Assim que um percentual vira objetivo, deixa de servir como medida. É a lei de Goodhart: quando uma medida se torna uma meta, deixa de ser uma boa medida [1]. Aplicada à cobertura, o resultado é previsível. Se a organização exige 90%, a equipe chegará a 90%. Mas não necessariamente testando melhor: às vezes escrevendo testes que executam código sem comprovar seu resultado, apenas para pintar a barra de verde.

Esses testes têm um ar inofensivo e são piores do que não ter nenhum. Dão uma sensação de segurança falsa. O código está "coberto", então ninguém desconfia dele, e quando falha, falha na zona que todos acreditavam estar a salvo. Uma suíte que sobe a cobertura sem subir a capacidade de detectar defeitos é puro teatro com custo de manutenção.

Aqui convém inverter a pergunta. A cobertura é excelente para o que não lhe diz, e pouco confiável para o que diz. Um 0% de cobertura em um módulo é um sinal duro e confiável: aquele código não é testado, ponto. A ausência informa. A presença, por outro lado, é ambígua: um 90% não garante que essas execuções tenham comprovado algo útil. Por isso a cobertura vale muito como detector de lacunas e pouco como certificado de qualidade. Leia-a ao contrário de como quase todo mundo a lê.

03 · o uso corretoFerramenta de diagnóstico, jamais objetivo de gestão

Então, joga-se fora? Não. Uma ferramenta usada mal não é uma ferramenta ruim. A cobertura, em mãos sensatas, é diagnóstico valioso. A chave está em mudar a pergunta que você faz a ela.

A pergunta errada é "qual percentual temos?". A certa é "quais partes importantes não estamos tocando?". O relatório de cobertura, lido pelas linhas vermelhas e não pelo número global, é um mapa dos seus pontos cegos. Ele mostra o tratamento de erros que ninguém exercitou, o ramo de configuração que nunca roda em testes, o caso-limite esquecido. Esse uso é ouro. O outro, perseguir um número, é a lei de Goodhart esperando para cobrar.

Não pergunte quanta cobertura você tem. Pergunte qual código importante ficou sem ser tocado.

Vale a pena ancorar isso no vocabulário do ofício. A ISO/IEC/IEEE 29119, o padrão internacional de testes de software, trata a cobertura como uma medida de completude dos testes frente a um critério, não como um fim em si mesma [2]. E o próprio glossário do ISTQB define a cobertura como o grau, expresso em percentual, em que um elemento específico foi exercitado por um conjunto de testes [3]. Repare na palavra: exercitado, não verificado. O padrão é honesto sobre o que mede. Somos nós que lhe pedimos para significar mais do que pode.

04 · o que medir em seu lugarComportamentos verificados, não linhas visitadas

Se a cobertura não é o objetivo, qual é? O objetivo real sempre foi o mesmo: detectar defeitos antes que o usuário o faça. E para isso convém olhar sinais que de fato se correlacionam com essa capacidade. Um é a qualidade das asserções: não quantas linhas você executa, mas quantas afirmações comprováveis você faz sobre o resultado. Outro, mais exigente, é o teste de mutação: a ferramenta introduz de propósito pequenos erros no seu código (troca um > por um >=, um + por um -) e verifica se seus testes os detectam. Se o código sofre mutação e seus testes continuam verdes, esses testes não estavam comprovando nada, por mais cobertura que reportem. A mutação mede o que a cobertura apenas aparenta.

Nada disso significa desprezar a cobertura. Significa colocá-la em seu lugar. É um instrumento de diagnóstico honesto sobre uma coisa concreta e estreita: o que foi executado. Pedir a ela que certifique qualidade é como pedir ao velocímetro que confirme que você chegou ao destino certo. Ele marca velocidade, não rumo.

Da próxima vez que você vir uma barra verde em 85%, resista ao alívio automático. Faça a pergunta incômoda: do que de fato foi executado, quanto foi realmente comprovado? Ali, nessa diferença entre visitar uma linha e verificar o que ela faz, mora quase tudo o que a cobertura lhe esconde justo quando você mais confia nela.