Code Coverage en desarrollo móvil: qué es, métricas y cómo medirlo

Qué es Code Coverage

Code Coverage (cobertura de código) es una métrica cuantitativa que determina qué parte del código fuente de la aplicación se ejecutó durante las pruebas. Se expresa en porcentaje y se calcula como la relación entre líneas/ramas ejecutadas y el total. Una cobertura alta no garantiza la ausencia de errores, pero reduce el riesgo de fallos no detectados.

Por qué medir la cobertura

La cobertura de código ayuda al equipo a: encontrar áreas no probadas del código, tomar decisiones sobre prioridades de escritura de pruebas y realizar un seguimiento de la dinámica de calidad de las pruebas en CI/CD. En el desarrollo móvil, la cobertura es especialmente importante para la lógica de negocio, los modelos de datos y los repositorios — capas donde la probabilidad de errores es más alta.

Mitos sobre Code Coverage

Un mito común: «100% de cobertura = calidad perfecta». En la práctica, el 100% de cobertura es extremadamente raro y a menudo se logra a costa de pruebas superficiales. La cobertura efectiva no es una carrera por el porcentaje, sino una cobertura estratégica de rutas críticas y condiciones límite. La cobertura no dice nada sobre la calidad de las pruebas en sí: una prueba puede pasar pero no verificar la corrección del resultado.

Métricas de cobertura de código

Existen varias métricas de Code Coverage, cada una mide diferentes aspectos de las pruebas. Line coverage (cobertura de líneas) es la métrica más simple, que muestra el porcentaje de líneas de código ejecutadas. Branch coverage (cobertura de ramas) mide qué bifurcaciones if-else y switch fueron probadas.

Cobertura de líneas (Line Coverage)

Line coverage cuenta cada línea de código fuente como ejecutada o no. Si una línea contiene un operador condicional o un bucle, la línea se considera ejecutada si el control llegó a ella, incluso si no todas las ramas fueron procesadas. Esta es la métrica menos estricta, pero la más comprensible para la evaluación visual.

Cobertura de ramas (Branch Coverage)

Branch coverage evalúa si todas las posibles ramas en el código fueron probadas. Para cada if-else se consideran ambas ramas: true y false. Para switch, cada case. Branch coverage se considera una métrica más estricta que line coverage y más a menudo revela escenarios no probados.

Cobertura de rutas (Path Coverage)

Path coverage es la métrica más estricta, que requiere verificar todas las posibles combinaciones de ramas en una función. En la práctica, path coverage rara vez se usa debido al crecimiento exponencial del número de combinaciones: una función con 10 ramas tiene 1024 rutas posibles.

Herramientas para medir la cobertura

En el desarrollo móvil se utilizan diversas herramientas para medir Code Coverage según la plataforma. Para Android, el estándar es JaCoCo (Java Code Coverage), que se integra con Gradle y admite tanto pruebas unitarias como pruebas de instrumentación. Para iOS se utiliza XCCov, integrado en Xcode.

JaCoCo para Android

JaCoCo genera informes en formatos HTML, XML y CSV. El informe HTML resalta visualmente las líneas: verde — ejecutadas, rojo — omitidas, amarillo — parcialmente ejecutadas. El informe XML es compatible con SonarQube y otros sistemas de análisis de código. JaCoCo admite filtrado de clases: se puede excluir código generado, databinding y BuildConfig.

// build.gradle — configuración de JaCoCo
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// Generación de informe JaCoCo
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

XCCov para iOS

XCCov es una herramienta integrada de Xcode para medir la cobertura de código. Se activa mediante Gather coverage data en el esquema de pruebas. XCCov admite cobertura para Swift y Objective-C, genera informes en .xccovreport y se integra con CI mediante xcodebuild -enableCodeCoverage YES. Los datos se muestran en la consola y se pueden exportar en JSON.

SonarQube y Codecov

Para la monitorización centralizada de la cobertura se utilizan plataformas como SonarQube (análisis de calidad de código + cobertura), Codecov y Coveralls. Estos servicios agregan datos de JaCoCo y XCCov, muestran tendencias, Quality Gate e integración con GitHub/GitLab mediante comentarios en PR.

Cómo mejorar la cobertura de código

Mejorar Code Coverage requiere un enfoque sistemático: no «subir porcentajes», sino cubrir riesgos. El primer paso es analizar el informe de JaCoCo o XCCov — identificar las clases rojas (no cubiertas). Prioridad: lógica de negocio → repositorios → ViewModel → componentes de UI.

Estrategia TDD

Test-Driven Development (TDD) garantiza automáticamente una alta cobertura, ya que las pruebas se escriben antes de la implementación. El proceso: rojo (escribir una prueba que falla) → verde (escribir código mínimo) → refactorización. TDD disciplina al desarrollador, obligándolo a cubrir casos límite y situaciones excepcionales que a menudo quedan sin pruebas.

Pruebas parametrizadas

Una prueba parametrizada reemplaza docenas de pruebas comunes. JUnit y XCTest admiten parametrización: @ParameterizedTest en JUnit 5, XCTestCase con testPerformanceExample en XCTest. La parametrización permite verificar múltiples datos de entrada sin duplicación de código, lo que amplía significativamente la cobertura de ramas y condiciones.

// Prueba parametrizada en Kotlin con JUnit 5
@ParameterizedTest
@ValueSource(strings = ["user@test.com", "admin@test.com", "test@example.com"])
fun `validate email returns true for valid addresses`(email: String) {
    val result = EmailValidator.isValid(email)
    Assertions.assertTrue(result)
}

Errores al trabajar con Code Coverage

El error más común es perseguir el porcentaje sin analizar la calidad de las pruebas. El equipo comienza a escribir pruebas por escribir: verifica getters y setters, duplica la cobertura en diferentes niveles, prueba métodos triviales. Esto da un alto porcentaje pero no mejora la calidad real.

Falsa sensación de seguridad

Un Code Coverage alto puede crear la falsa sensación de que la aplicación está bien probada. Una prueba puede ejecutar una línea de código pero no verificar la corrección del resultado. Por ejemplo: una prueba llama a un método de cálculo de descuento pero no verifica el monto — la línea se ejecuta, la cobertura crece, pero el error no se encuentra.

Ignorar casos límite

Un error típico es probar solo el «camino feliz» (happy path) e ignorar los casos límite: listas vacías, valores null, números máximos, formatos incorrectos. Es precisamente en los límites y excepciones donde ocurren la mayoría de los errores. Branch coverage ayuda a identificar ramas omitidas, pero no garantiza la verificación de valores límite.

Mutation Testing — verificación de la calidad de las pruebas

Mutation Testing es un método para evaluar la calidad de las pruebas donde se introducen mutaciones (errores artificiales) en el código fuente y se verifica si las pruebas fallan. Pitest es una herramienta popular de mutation testing para Java y Kotlin. Si las pruebas no fallan ante una mutación, significa que no verifican esa condición.

Principio de funcionamiento de Pitest

Pitest crea mutantes — copias modificadas del código fuente donde, por ejemplo, > se reemplaza por >=, true por false, o se elimina una llamada a método. Luego, para cada mutante se ejecutan las pruebas. Si las pruebas pasan — el mutante sobrevivió, lo que significa que las pruebas no cubren ese escenario. Si las pruebas fallan — el mutante ha sido eliminado, la prueba es correcta.

// build.gradle — configuración de Pitest
plugins {
    id 'info.solidsoft.pitest' version '1.15.0'
}

pitest {
    targetClasses = ['com.example.app.*']
    targetTests = ['com.example.app.*Test']
    threads = 4
    outputFormats = ['HTML', 'XML']
    mutationThreshold = 80
    coverageThreshold = 85
}

Tipos de mutaciones

Pitest admite muchos tipos de mutaciones: cambio de operadores condicionales (== → !=, < → <=), eliminación de llamadas a métodos, reemplazo de valores de retorno (true → false), cambio de operaciones aritméticas (+ → -), mutación de incrementos (i++ → i--). Cuantos más tipos de mutaciones sean eliminados por las pruebas, más confiable es el conjunto de pruebas.

Objetivo de Mutation Score

El mutation score objetivo es del 80% o más. Esto significa que el 80% de los errores artificiales son detectados por las pruebas. Una cobertura de código (Code Coverage) del 90% no garantiza que las pruebas encuentren errores — mutation testing proporciona una evaluación más objetiva. Pitest puede integrarse en CI como Quality Gate, bloqueando la compilación si el mutation score cae por debajo del umbral.

Integración de Code Coverage en CI/CD

Para el control automático de Code Coverage en CI/CD se utilizan Quality Gates — valores umbral que, al ser violados, marcan la compilación como inestable o la rechazan. SonarQube permite configurar un Quality Gate basado en una combinación de métricas: cobertura (≥80%), número de errores, vulnerabilidades y código duplicado.

Configuración de Quality Gate en GitHub Actions

En GitHub Actions, Code Coverage se integra mediante pasos de acción: ejecutar pruebas con cobertura → cargar informe en Codecov → verificar umbral. Codecov comenta automáticamente en los PR con el diff de cobertura, mostrando qué líneas cambiaron y cómo afectó al porcentaje general. Si la cobertura bajó, el PR se bloquea hasta que se escriban pruebas adicionales.

# GitHub Actions — carga de cobertura a Codecov
- name: Run Tests with Coverage
  run: ./gradlew testDebugUnitTest jacocoTestReport

- name: Upload to Codecov
  uses: codecov/codecov-action@v4
  with:
    files: ./app/build/reports/jacoco/jacocoTestReport.xml
    flags: unittests
    fail_ci_if_error: true

- name: Check Coverage Threshold
  run: |
    coverage=$(grep -oP 'branchCoverage="\K[0-9.]+' report.xml)
    if (( $(echo "$coverage < 80" | bc -l) )); then
      echo "Coverage $coverage% is below 80% threshold"
      exit 1
    fi

Informes y visualización

Los informes HTML de JaCoCo y XCCov contienen resaltado visual de cobertura: verde — líneas ejecutadas, rojo — no ejecutadas. SonarQube además muestra la cobertura a nivel de archivo, clase, método y línea, así como el historial de cambios de cobertura por sprints. Esto ayuda a tomar decisiones sobre refactorización y adición de pruebas.