Cobertura de pruebas en código de IA: por qué el porcentaje engaña

La cobertura de pruebas mide qué líneas de código se ejecutaron en una pasada de pruebas, no si se comprobó el comportamiento. En las pruebas generadas por IA se añade un razonamiento circular: el modelo deriva los valores esperados del comportamiento del código que debe comprobar. Si el código contiene un error, el error se convierte en una aserción. La prueba está en verde y protege el error.

¿Qué dice la cobertura de pruebas y qué no dice?

La cobertura es una estadística de ejecución. Responde a: ¿qué líneas, ramas o condiciones se tocaron durante la pasada de pruebas? No responde a: ¿se comprobó que el resultado fuera el correcto?

Una prueba que llama a una función y no contiene ni una sola aserción genera una cobertura total para esa función. No es un contraejemplo inventado: es un patrón que surge en cuanto se fija un umbral de cobertura como objetivo.

¿Por qué son especialmente engañosas las pruebas generadas por IA?

Porque se derivan del estado actual en lugar de un requisito. El proceso habitual es: el código existe, se pide al modelo que escriba pruebas para él, el modelo lee el código y genera aserciones que encajan con él.

El resultado parece una comprobación y es una descripción. Si el código calcula mal el IVA, la prueba generada espera el importe erróneo. Seguirá en verde de forma fiable, aunque alguien corrija el error más adelante; entonces falla y se considera rota.

Esta inversión explica parte de la fricción que los desarrolladores señalan con el código de IA: en la Stack Overflow Developer Survey 2025, el 45 % de los encuestados indicó perder un tiempo considerable depurando código generado por IA. Una prueba que arrastra el error en lugar de señalarlo alarga precisamente esa búsqueda.

Es la inversión del propósito real: una prueba debe fijar el comportamiento deseado, no el encontrado. Al asegurar código heredado, fijar el estado actual es expresamente lo que se quiere; en código nuevo, es un error. La diferencia debe ser conocida por el equipo, véase Modernizar código heredado con IA.

¿Qué métrica debería usar en su lugar?

La cobertura de las líneas modificadas, no la cobertura total. Hay tres razones a favor.

• Es controlable. La cobertura total de un proyecto crecido apenas se mueve, haga lo que haga: el denominador es demasiado grande. La cobertura de lo nuevo reacciona de inmediato.
• Es justa. Nadie es responsabilizado de una herencia que no causó.
• Actúa de forma acumulativa. Si cada cambio está bien cubierto, el valor total sube por sí solo, allí donde realmente se trabaja.

Como umbral sirve lo siguiente: la cobertura de las líneas modificadas no es inferior al valor existente del proyecto. Esta regla no necesita un porcentaje arbitrario e impide el deterioro.

¿Cómo compruebo si mis pruebas valen para algo?

Con pruebas de mutación, el único método extendido que mide la calidad de las propias pruebas.

El procedimiento es sencillo: una herramienta modifica el código de producción de forma dirigida y mínima (invierte un operador de comparación, sustituye un valor de retorno, elimina una llamada) y ejecuta las pruebas. Si ninguna prueba advierte el cambio, el conjunto de pruebas tiene en ese punto una laguna, con independencia de lo que diga la cobertura.

Esta comprobación es precisamente la que desenmascara el razonamiento circular de más arriba: una prueba cuyas aserciones se derivaron del código sobrevive a algunas mutaciones, porque no fija realmente el comportamiento. Las pruebas de mutación consumen mucho cálculo y no pertenecen a cada ejecución; una vez por semana o sobre los módulos críticos basta para obtener la información.

¿Qué pruebas necesita especialmente el código generado por IA?

Pruebas para los casos que no aparecían en el prompt: ahí están las lagunas acreditadas.

• Casos de error. Entrada ausente, tipo incorrecto, lista vacía, tiempo de espera agotado del servicio externo. Las excepciones mal tratadas son desde 2025 una categoría propia de OWASP (A10).
• Permisos. Una prueba que compruebe que otro usuario no puede. El control de acceso defectuoso ocupa el primer puesto en los OWASP Top 10:2025, y esta comprobación es la que con más frecuencia falta en el código generado.
• Límites. Cero, uno, el máximo, uno por encima.
• Concurrencia. Dos operaciones sobre el mismo registro. Nunca ocurrió en el prototipo, y en producción ocurre el primer día.

Estos cuatro grupos, por cierto, una IA puede escribirlos bien en cuanto se le pide expresamente. El punto es que por sí sola no lo pide.

Preguntas frecuentes sobre la cobertura de pruebas

¿Qué cobertura de pruebas es suficiente?

No existe una cifra universal, y cualquier porcentaje que se cite es convención, no norma. La regla relativa es sólida: el código nuevo no queda por debajo del valor existente del proyecto.

¿Debo dejar que una IA escriba las pruebas?

Sí, pero con el orden invertido: describa primero el comportamiento deseado en prosa y haga generar pruebas a partir de eso, no a partir del código terminado. Así surge una comprobación en lugar de una descripción.

¿Cuál es la diferencia entre cobertura de líneas y cobertura de ramas?

La cobertura de líneas cuenta las líneas ejecutadas; la cobertura de ramas cuenta los caminos de ramificación recorridos. Una condición con dos ramas alcanza la cobertura de líneas total si solo se probó uno de los dos caminos. La cobertura de ramas es la cifra más reveladora.

¿Merecen la pena las pruebas de extremo a extremo con código de IA?

Para los caminos principales, sí, porque comprueban la interacción, y precisamente ahí están los errores del código generado con más frecuencia que en funciones aisladas. Como cobertura amplia son demasiado lentas y frágiles.

Una pasada de pruebas en verde solo es una prueba fehaciente cuando no se limita a afirmarse. Code Guardian exige, al cerrar cada cambio, la salida de la comprobación, y ni siquiera deja pasar un cambio sin pruebas.

Fuentes

• OWASP Top 10:2025, categorías A01 «Broken Access Control» y A10 «Mishandling of Exceptional Conditions».
• Stack Overflow Developer Survey 2025 (el 45 % de los encuestados pierde un tiempo considerable depurando código de IA).

Fecha: 27 de julio de 2026. Valoración técnica general.