Cobertura de código con pruebas en Kotlin: de 0 a 80% en una tarde

Introducción: ¿Por qué las pruebas "verdes" son una ilusión?

Ejecutas las pruebas, ves la ansiada barra verde y te sientes un superhéroe. Pero, ¿y si te dijera que tus pruebas podrían ser inútiles? ¿Que solo verifican una línea de cada diez, y las otras nueve son una "zona muerta" donde viven los errores? Aquí es donde entra en escena la cobertura de código con pruebas (code coverage). No son solo números para un informe, sino tu radar personal que muestra qué tan bien las pruebas "cubren" tu código Kotlin.

En este artículo, analizaremos cómo convertir la cobertura de código en Kotlin de una métrica aburrida a una herramienta poderosa. Aprenderás qué herramientas realmente funcionan, qué significan los porcentajes y cómo no caer en la trampa del "100% de cobertura". ¡Allá vamos!

¿Qué es la cobertura de código y por qué es importante para Kotlin?

Imagina que tu código es un campo de golf y las pruebas son los jugadores. La cobertura de código es un mapa que muestra por qué partes del campo han pasado los jugadores. Si los jugadores evitan un búnker peligroso (un algoritmo complejo), lo sabrás.

En el mundo de Kotlin, donde a menudo usamos corrutinas, clases selladas y funciones de extensión, las pruebas ingenuas pueden pasar fácilmente por alto ramas enteras de lógica. Las métricas de cobertura ayudan a responder tres preguntas:

\n
• ¿Qué porcentaje de líneas de código se ejecutó durante las pruebas?
\n
• ¿Qué condiciones (if/else, when) se verificaron?
\n
• ¿Qué funciones quedaron sin atención?
\n

Sin estas métricas, corres el riesgo de lanzar a producción código que funciona "solo los lunes".

Herramientas para medir la cobertura en Kotlin: Top 3

En el ecosistema de Kotlin hay tres protagonistas principales que te ayudarán a medir el code coverage. Conozcamos a cada uno.

1. JaCoCo (Java Code Coverage) — El veterano

La herramienta más popular. Funciona a nivel de bytecode, por lo que es adecuada tanto para Java como para Kotlin. Su principal ventaja es la rica estadística y la integración con CI/CD.

Cómo conectarlo en Gradle (Kotlin DSL):

plugins {\n    id("jacoco")\n}\n\ntasks.jacocoTestReport {\n    dependsOn(tasks.test) // Ejecutamos las pruebas antes del informe\n    reports {\n        xml.required.set(true)\n        html.required.set(true) // Generamos un bonito informe HTML\n    }\n}

Después de ejecutar ./gradlew jacocoTestReport obtendrás un archivo HTML donde las líneas no cubiertas se resaltan en rojo. Práctico, ¿verdad?

2. Kover — El jugador moderno

Diseñado específicamente para Kotlin. A diferencia de JaCoCo, Kover funciona a nivel de AST (árbol de sintaxis abstracta), lo que lo hace más preciso para construcciones específicas de Kotlin (por ejemplo, funciones inline).

Conexión de Kover:

plugins {\n    id("org.jetbrains.kotlinx.kover") version "0.7.3"\n}\n\nkover {\n    excludeSourceSets {\n        names("test") // Excluimos las propias pruebas del informe\n    }\n}

Kover genera informes en formatos HTML, XML e incluso como insignias para GitHub. Es la elección ideal para un proyecto puro de Kotlin.

3. IntelliJ IDEA Coverage — Para una verificación rápida

Herramienta integrada. Ejecutas las pruebas con cobertura (icono verde "Run with Coverage") y ves el código coloreado directamente en el IDE. Es útil para el desarrollo local, pero no para CI.

Consejo: Usa IntelliJ para iteraciones rápidas, y JaCoCo o Kover para el informe final.

Métricas de cobertura de código: ¿Qué significan estos porcentajes?

Cuando ves "80% de cobertura", suena genial. Pero, ¿80% de qué? Analicemos las métricas principales que proporcionan todas las herramientas.

Line Coverage (Cobertura de líneas)

La métrica más simple. Cuántas líneas del código fuente fueron tocadas por las pruebas. Si una línea no se ejecuta ni una vez, se considera no cubierta.

Ejemplo:

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