Cobertura de código com testes em Kotlin: de 0 a 80% em uma noite

Introdução: Por que os testes "verdes" são uma ilusão?

Você executa os testes, vê a tão esperada barra verde e se sente um super-herói. Mas e se eu disser que seus testes podem ser inúteis? Que eles testam apenas uma linha em cada dez, e as outras nove são uma "zona morta" onde vivem os bugs? É aqui que entra em cena a cobertura de código com testes (code coverage). Não são apenas números para um relatório, mas seu radar pessoal, mostrando o quão bem os testes "cobrem" seu código Kotlin.

Neste artigo, vamos explorar como transformar a cobertura de código em Kotlin de uma métrica chata em uma ferramenta poderosa. Você aprenderá quais ferramentas realmente funcionam, o que significam as porcentagens e como não cair na armadilha dos "100% de cobertura". Vamos lá!

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

Imagine que seu código é um campo de golfe e os testes são os jogadores. A cobertura de código é um mapa que mostra por quais áreas do campo os jogadores passaram. Se os jogadores evitam um bunker perigoso (algoritmo complexo), você fica sabendo.

No mundo Kotlin, onde frequentemente usamos corrotinas, classes sealed e funções de extensão, testes ingênuos podem facilmente ignorar ramos inteiros da lógica. As métricas de cobertura ajudam a responder três perguntas:

\n
• Qual porcentagem de linhas de código foi executada durante os testes?
\n
• Quais condições (if/else, when) foram testadas?
\n
• Quais funções ficaram sem atenção?
\n

Sem essas métricas, você corre o risco de lançar em produção um código que funciona "apenas às segundas-feiras".

Ferramentas para medir cobertura em Kotlin: Top 3

No ecossistema Kotlin, existem três principais protagonistas que ajudarão você a medir o code coverage. Vamos conhecer cada um.

1. JaCoCo (Java Code Coverage) — O Veterano

A ferramenta mais popular. Funciona no nível do bytecode, portanto é adequada tanto para Java quanto para Kotlin. Sua principal vantagem são as estatísticas ricas e a integração com CI/CD.

Como configurar no Gradle (Kotlin DSL):

plugins {\n    id("jacoco")\n}\n\ntasks.jacocoTestReport {\n    dependsOn(tasks.test) // Executa os testes antes do relatório\n    reports {\n        xml.required.set(true)\n        html.required.set(true) // Gera um belo relatório HTML\n    }\n}

Após executar ./gradlew jacocoTestReport, você obterá um arquivo HTML onde as linhas não cobertas são destacadas em vermelho. Prático, não é?

2. Kover — O Jogador Moderno

Desenvolvido especificamente para Kotlin. Ao contrário do JaCoCo, o Kover funciona no nível da AST (árvore sintática abstrata), tornando-o mais preciso para construções específicas do Kotlin (por exemplo, funções inline).

Configuração do Kover:

plugins {\n    id("org.jetbrains.kotlinx.kover") version "0.7.3"\n}\n\nkover {\n    excludeSourceSets {\n        names("test") // Exclui os próprios testes do relatório\n    }\n}

O Kover gera relatórios nos formatos HTML, XML e até mesmo como badges para o GitHub. É a escolha ideal para um projeto puramente Kotlin.

3. IntelliJ IDEA Coverage — Para verificação rápida

Ferramenta integrada. Você executa os testes com cobertura (ícone verde "Run with Coverage") e vê o código colorido diretamente na IDE. Prático para desenvolvimento local, mas não para CI.

Dica: Use o IntelliJ para iterações rápidas, e o JaCoCo ou Kover para o relatório final.

Métricas de cobertura de código: O que significam essas porcentagens?

Quando você vê "80% de cobertura", parece legal. Mas 80% do quê? Vamos analisar as principais métricas que todas as ferramentas fornecem.

Line Coverage (Cobertura de linhas)

A métrica mais simples. Quantas linhas do código-fonte foram afetadas pelos testes. Se uma linha não foi executada nenhuma vez, ela é considerada não coberta.

Exemplo:

fun process(value: Int): String {\n    if (