Cobertura de Código com Testes em Java: do JUnit ao JaCoCo na Prática

Cobertura de Código com Testes em Java: Ferramentas e Métricas na Prática

Você já se sentiu como o capitão de um navio que tem certeza de que sua embarcação é inafundável, mas nunca verificou se o casco tem buracos? Mais ou menos assim é o desenvolvimento em Java sem a análise de cobertura de código com testes. Você escreve testes, mas não sabe o quão eficazes eles são para proteger seu projeto contra bugs. Neste artigo, vamos explorar o que é cobertura de código com testes em Java, quais ferramentas de cobertura de código realmente ajudam a não afundar em regressões e como interpretar as métricas corretamente para não enganar a si mesmo.

Por que simplesmente "escrever testes" não é suficiente?

Muitos desenvolvedores pensam: "Escrevi 50 testes — então o projeto está protegido". Mas a quantidade de testes não equivale à qualidade. Sem métricas, você corre o risco de:

\n
• Perder ramos inteiros da lógica (por exemplo, tratamento de exceções);
\n
• Testar apenas os "caminhos felizes", ignorando casos limite;
\n
• Perder tempo com testes que não verificam o novo código.
\n

É aqui que o code coverage Java entra em cena — uma avaliação objetiva de qual porcentagem do código-fonte é executada durante os testes. Não é uma panaceia, mas uma bússola poderosa para a equipe.

Principais métricas de cobertura de código em Java

Antes de escolher uma ferramenta, vamos entender o que exatamente estamos medindo. No mundo Java, existem quatro métricas principais:

1. Cobertura de Linhas (Line Coverage)

A métrica mais simples: quantas linhas de código foram executadas pelo menos uma vez. Se uma linha não foi executada, significa que ninguém a testou. Exemplo:

public int divide(int a, int b) {\n    if (b == 0) {\n        throw new IllegalArgumentException("Division by zero"); // Linha 3\n    }\n    return a / b; // Linha 5\n}

Se o seu teste chama divide(10, 2), a linha 3 permanecerá sem cobertura. A cobertura de linhas Java mostrará 50%.

2. Cobertura de Ramos (Branch Coverage)

Esta métrica é mais sutil. Ela verifica se todos os caminhos lógicos (if-else, switch, operadores ternários) foram percorridos. Para o mesmo método divide:

\n
• Ramo 1: b == 0 (true) — lançamento de exceção;
\n
• Ramo 2: b != 0 (false) — divisão.
\n

Se você testou apenas a divisão, a cobertura de ramos será de 50%. Se adicionar um teste com b=0, ela se torna 100%.

3. Cobertura de Condições (Condition Coverage)

Uma métrica mais profunda que analisa cada subcondição em expressões complexas. Por exemplo, no código if (a > 0 && b < 10), é necessário verificar 4 combinações: (true, true), (true, false), (false, true), (false, false).

4. Cobertura de Mutações (Mutation Coverage)

O padrão ouro. A ferramenta (por exemplo, PIT) faz pequenas alterações no código — muda >= para <, remove uma chamada de método — e verifica se pelo menos um teste falha. Se nenhum teste falhar, significa que ele não é sensível o suficiente. O teste de mutação Java é a melhor forma de avaliar a qualidade dos testes, mas é mais lento.

Principais ferramentas de cobertura de código para Java

O mercado oferece várias soluções maduras. Vamos ver as mais populares.

JaCoCo — o padrão da indústria

JaCoCo (Java Code Coverage) é uma biblioteca open-source que se integra ao build (Maven, Gradle) e gera relatórios em HTML, XML ou CSV. Ele suporta todas as métricas principais, exceto mutações.

Exemplo de configuração no Maven (pom.xml):

<plugin>\n    <groupId>org.jacoco</groupId>\n    <artifactId>jacoco-maven-plugin</artifactId>\n    <version>0.8.11</version>\n    <executions>\n        <execution>\n            <goals>\n                <goal>prepare-agent</goal>\n            </goals>\n        </execution>\n        <execution>\n