Cobertura de testes JavaScript: ferramentas e métricas de código

Cobertura de código com testes em JavaScript: ferramentas e métricas

Imagine que você é o capitão de um enorme navio. Sua equipe verifica regularmente os motores, a navegação e os sistemas de segurança. Mas um dia você decide não verificar o sistema de refrigeração porque "funcionou ontem". O resultado é previsível: superaquecimento, quebra, e você fica à deriva em alto mar. No mundo JavaScript, essa negligência é chamada de "falta de cobertura de código com testes".

Você escreve testes — isso é ótimo. Mas como saber se você realmente verificou tudo, e não apenas criou uma ilusão de segurança? A resposta são as métricas de cobertura de código. Elas mostram qual parte da sua aplicação foi executada durante os testes. Sem essas métricas, você corre o risco de perder um bug crítico escondido em um ramo de condição não testado.

Neste artigo, vamos explorar como medir corretamente a cobertura de código com testes em JavaScript, quais ferramentas existem para isso e como interpretar as métricas para não se prejudicar. Mergulhamos no mundo do code coverage sem tédio!

O que é cobertura de código e por que é importante?

Cobertura de código (code coverage) é uma métrica que mostra quantas linhas, funções ou ramos do seu código foram executados durante a execução dos testes. Simplificando, é a porcentagem de código "verificado".

Muitos desenvolvedores acreditam que 100% de cobertura é o Santo Graal. Mas não é bem assim. A cobertura é uma ferramenta, não um objetivo. Ela ajuda a:

\n
• Encontrar código "morto" que nunca é executado (e talvez não seja necessário).
\n
• Entender quais partes do código ficaram sem testes e avaliar o risco.
\n
• Aumentar a confiança em refatorações: se a cobertura não caiu, você não quebrou nada.
\n

Mas também há armadilhas. 100% de cobertura não garante a ausência de bugs. Você pode verificar todas as linhas, mas perder um erro lógico nas regras de negócio. Portanto, a cobertura de testes JavaScript deve ser considerada em conjunto com a qualidade dos próprios testes.

Principais métricas de cobertura de código

Antes de escolher uma ferramenta, vamos entender quais métricas existem. As métricas de cobertura de código são divididas em vários tipos, e cada um responde a uma pergunta específica.

Cobertura de Linhas (Line Coverage)

A métrica mais simples. Ela mostra quantas linhas do código fonte foram executadas pelo menos uma vez. Se você tem 100 linhas e os testes executaram 80, a cobertura de linhas é de 80%.

Cobertura de Ramos (Branch Coverage)

Uma métrica mais profunda. Ela analisa todos os caminhos possíveis de execução do código (ramos if/else, operadores ternários, switch). Por exemplo, se você tem uma condição if (a > 5), existem dois ramos: true e false. Se o seu teste verifica apenas o caso em que a > 5, a cobertura de ramos será de 50%.

Cobertura de Funções (Function Coverage)

Mostra quantas funções (ou métodos) foram chamadas durante os testes. Se uma função é declarada, mas nunca chamada, ela não está coberta.

Cobertura de Instruções (Statement Coverage)

Semelhante à cobertura de linhas, mas opera com instruções individuais (expressões) em vez de linhas. Em JavaScript, esses conceitos frequentemente se sobrepõem, mas formalmente são coisas diferentes.

Para projetos reais, a análise de cobertura JS geralmente inclui todas as quatro métricas. Mas a atenção principal deve ser dada à cobertura de ramos, pois é ela que revela cenários não testados.

Ferramentas para medir cobertura em JavaScript

Felizmente, o ecossistema JavaScript é rico em ferramentas. Vamos analisar as mais populares: das simples às avançadas.

Istanbul (nyc) — o padrão ouro

Istanbul é a ferramenta mais popular para medir a cobertura de código com testes JavaScript. Ela funciona com praticamente qualquer test runner: Jest, Mocha, Ava, Cypress. Após a instalação, você simplesmente executa os testes com o wrapper nyc.

Exemplo de instalação e execução: