Cobertura de código: la métrica que más miente cuando más la miras

Un equipo celebra que llegó al 85% de cobertura. En el tablero, la barra se pinta de verde y todos respiran. Dos semanas después, un bug elemental llega a producción: una resta que debía validar un saldo devolvía el signo cambiado. Lo raro no es que el bug existiera. Lo raro es que la línea con el error estaba cubierta. Las pruebas la ejecutaron. Y aun así, nadie la verificó.

La respuesta corta a por qué pasa esto: la cobertura mide qué código se ejecutó durante las pruebas, no qué comportamiento se comprobó. Son cosas distintas, y confundirlas es el error más caro y más común en la gestión de calidad. La cobertura es un velocímetro que te dice a qué velocidad pasaste por cada tramo del camino, pero no si mirabas la carretera.

01 · qué mideEjecutar una línea no es lo mismo que probarla

La cobertura de código es una medida de cuánto de tu código fuente fue recorrido mientras corría un conjunto de pruebas. Un instrumento observa la ejecución y anota qué líneas, qué ramas y qué condiciones se activaron. Al final divide lo recorrido entre lo total y te entrega un porcentaje. Eso es todo lo que hace: contar visitas.

El problema aparece en el salto que la mente hace sola. Ver "85% de cobertura" y leer "85% probado" es un espejismo tan natural que casi nadie lo nota. Una prueba puede llamar a una función, hacer que cada una de sus líneas se ejecute, y no comprobar nada del resultado. Si no hay una aserción que diga "el saldo debe ser 100", la línea cuenta como cubierta aunque devuelva basura.

La cobertura cuenta líneas visitadas. La calidad depende de comportamientos verificados. No es lo mismo.

Hay varios tipos, y ordenarlos importa porque no exigen lo mismo. La cobertura de líneas pregunta si cada línea se ejecutó. La cobertura de ramas pregunta si cada bifurcación (cada if) se tomó por ambos caminos, el verdadero y el falso. La cobertura de condiciones baja aún más: dentro de un if con varias condiciones unidas por and u or, pregunta si cada condición individual fue verdadera y falsa alguna vez. Un 100% de líneas puede convivir con un 50% de ramas: basta con nunca haber probado el camino del else.

02 · la trampaCuando el número sube y la calidad no se mueve

La trampa mayor no es técnica, es humana, y tiene nombre. En cuanto un porcentaje se convierte en objetivo, deja de servir como medida. Es la ley de Goodhart: cuando una medida se vuelve una meta, deja de ser una buena medida [1]. Aplicada a la cobertura, el resultado es predecible. Si la organización exige 90%, el equipo llegará a 90%. Pero no necesariamente probando mejor: a veces escribiendo pruebas que ejecutan código sin comprobar su resultado, solo para pintar la barra de verde.

Estas pruebas tienen un aire inofensivo y son peores que no tener ninguna. Dan una sensación de seguridad falsa. El código está "cubierto", así que nadie sospecha de él, y cuando falla, falla en la zona que todos creían a salvo. Una suite que sube la cobertura sin subir la capacidad de detectar defectos es puro teatro con costo de mantenimiento.

Aquí conviene invertir la pregunta. La cobertura es excelente para lo que no te dice bien de lo que sí. Un 0% de cobertura en un módulo es una señal dura y confiable: ese código no se prueba, punto. La ausencia informa. La presencia, en cambio, es ambigua: un 90% no garantiza que esas ejecuciones comprobaran algo útil. Por eso la cobertura vale mucho como detector de huecos y poco como certificado de calidad. Léela al revés de como la lee casi todo el mundo.

03 · el uso correctoHerramienta de diagnóstico, jamás objetivo de gestión

Entonces, ¿se tira a la basura? No. Una herramienta que se usa mal no es una mala herramienta. La cobertura, en manos sensatas, es diagnóstico valioso. La clave está en cambiar la pregunta que le haces.

La pregunta equivocada es "¿qué porcentaje tenemos?". La correcta es "¿qué partes importantes no estamos tocando?". El reporte de cobertura, leído por líneas rojas y no por el número global, es un mapa de tus puntos ciegos. Te muestra el manejo de errores que nadie ejercitó, la rama de configuración que nunca corre en pruebas, el caso límite olvidado. Ese uso es oro. El otro, perseguir un número, es la ley de Goodhart esperando a cobrar.

No preguntes cuánta cobertura tienes. Pregunta qué código importante quedó sin tocar.

Vale la pena anclar esto en el vocabulario del oficio. La ISO/IEC/IEEE 29119, el estándar internacional de pruebas de software, trata la cobertura como una medida de completitud de las pruebas frente a un criterio, no como un fin en sí mismo [2]. Y el propio glosario del ISTQB define la cobertura como el grado, expresado en porcentaje, en que un elemento específico ha sido ejercitado por un conjunto de pruebas [3]. Fíjate en la palabra: ejercitado, no verificado. El estándar es honesto sobre lo que mide. Somos nosotros los que le pedimos que signifique más de lo que puede.

04 · qué medir en su lugarComportamientos verificados, no líneas visitadas

Si la cobertura no es el objetivo, ¿cuál es? El objetivo real siempre fue el mismo: detectar defectos antes que el usuario. Y para eso conviene mirar señales que sí se correlacionan con esa capacidad. Una es la calidad de las aserciones: no cuántas líneas ejecutas, sino cuántas afirmaciones comprobables haces sobre el resultado. Otra, más exigente, es la prueba de mutación: la herramienta introduce a propósito pequeños errores en tu código (cambia un > por un >=, un + por un -) y verifica si tus pruebas los detectan. Si el código muta y tus pruebas siguen en verde, esas pruebas no estaban comprobando nada, por mucha cobertura que reporten. La mutación mide lo que la cobertura solo aparenta.

Nada de esto significa despreciar la cobertura. Significa ponerla en su sitio. Es un instrumento de diagnóstico honesto sobre una cosa concreta y estrecha: qué se ejecutó. Pedirle que certifique calidad es como pedirle al velocímetro que confirme que llegaste al destino correcto. Marca velocidad, no rumbo.

La próxima vez que veas una barra verde en el 85%, resiste el alivio automático. Haz la pregunta incómoda: de lo que sí se ejecutó, ¿cuánto se comprobó de verdad? Ahí, en esa diferencia entre visitar una línea y verificar lo que hace, vive casi todo lo que la cobertura te oculta cuando más confías en ella.