Tests generados por IA: por qué más pruebas no bastan

Pedir a una herramienta de inteligencia artificial «genera tests para este módulo» puede producir muchos casos. Es tentador presentar el aumento del recuento como una mejora automática. Pero una prueba que ejecuta una función sin comprobar su resultado, una que repite el mismo camino con otros nombres o una que afirma exactamente el comportamiento erróneo del programa puede dejar los defectos en su sitio. El número de archivos o de casos ejecutados no responde a la pregunta decisiva: ¿qué error concreto detectaría cada prueba?

Ilustración conceptual generada para Gaia; no muestra resultados de un proyecto real. Crédito: Gaia Genis Hub.

Tres cifras que conviene separar

El número de tests cuenta unidades de ejecución; depende de cómo se divida la suite. La cobertura de líneas o ramas mide qué código se recorrió. JaCoCo documenta que la cobertura de instrucciones observa bytecode ejecutado y la de ramas observa las alternativas de condiciones como if o switch. Es posible ejecutar una línea y no comprobar nada significativo sobre ella.

La tercera pregunta es si la suite detecta cambios incorrectos. El proyecto PIT Mutation Testing introduce modificaciones automáticas en el código y ejecuta los tests: si fallan, se dice que el mutante ha sido «eliminado»; si pasan, ese cambio sobrevivió. PIT explica que la cobertura tradicional registra ejecución, pero no demuestra que los tests distingan el comportamiento correcto del incorrecto. La mutación tampoco certifica por sí sola la calidad global: depende de los mutantes disponibles, de la configuración y de qué código se incluye.

Una misma función puede tener cobertura de líneas alta y un test superficial. Imagina una función que aplica un descuento solo si el pedido supera un umbral. Una prueba que llama a la función con un pedido cualquiera y verifica que la respuesta «existe» puede recorrer las líneas. No comprueba el límite exacto, el importe calculado ni que un pedido justo por debajo del umbral conserve el precio. Si la IA crea cinco variantes de esa prueba, habrá más tests, pero la omisión seguirá ahí.

El riesgo específico de generar pruebas desde el código

Una herramienta que ve solo la implementación puede copiar los supuestos del mismo código que debería examinar. Si la función devuelve mal un total, el modelo podría escribir una expectativa basada en ese total erróneo. En un experimento de Konstantinou, Degiovanni y Papadakis con casos de 24 repositorios Java, los oráculos generados con los enfoques de modelos estudiados tendieron a reflejar el comportamiento real del programa, lo que dificultó encontrar fallos.

Ese resultado no mide todas las herramientas de IA ni todos los lenguajes, pero ilustra el riesgo. Por eso el punto de partida debe incluir una regla independiente: especificación, ejemplo de producto aprobado o comportamiento acordado por el equipo. El oráculo de la prueba no debería derivarse únicamente de la salida actual de la función.

Las pruebas generadas también pueden ser frágiles. Comprobar textos de interfaz, posiciones de elementos o detalles privados de una función en lugar de un resultado observable hace que fallen ante cambios legítimos y que el equipo termine ignorándolas. Esto es una posibilidad metodológica, no una medición de una herramienta concreta. No hemos comparado productos ni evaluado una suite de Gaia para este artículo.

Diagrama elaborado por Gaia con definiciones de JaCoCo y PIT; no contiene puntuaciones de ningún proyecto.

Un control de calidad que sirve antes de aceptar un test

Para cada prueba propuesta, anota en una frase el comportamiento que promete vigilar. Luego revisa cinco puntos:

1. Entrada y contexto. ¿Reproduce una condición relevante para el usuario o solo llama al método con datos arbitrarios?
2. Resultado esperado independiente. ¿La expectativa procede de un requisito verificable o se ha copiado del programa actual?
3. Aserción útil. Si el cálculo devolviera un valor incorrecto, ¿fallaría la prueba? Una aserción de «no es nulo» puede ser demasiado débil.
4. Límites y errores. ¿Cubre los bordes del umbral, el dato vacío o el fallo de dependencia que importa? Una condición puede tener dos ramas aunque se ejecute la línea donde aparece.
5. Mantenimiento. ¿Comprueba el comportamiento público o se romperá por un cambio interno que no afecta al usuario?

Después, ejecuta la suite y examina su cobertura con una herramienta apropiada para el lenguaje. No infieras que una cifra «100 %» equivale a ausencia de bugs. Si el proyecto y el coste lo permiten, una prueba de mutación acotada al código cambiado puede revelar aserciones débiles; PIT recomienda precisamente analizar con frecuencia el código modificado. Revisa manualmente los mutantes supervivientes: PIT explica que algunos cambios pueden ser equivalentes y no alterar el comportamiento observable.

Cómo pedir mejor ayuda a la IA

En vez de «crea todos los tests», entrega el contrato de la función, ejemplos correctos y contraejemplos. Pide primero una matriz de escenarios con entradas, resultados esperados, fuente del requisito y fallo que detectaría cada caso. Revisa esa matriz antes de generar código. Después solicita tests pequeños con nombres que describan el comportamiento, no la implementación. Esta secuencia no garantiza buenas pruebas, pero facilita detectar duplicaciones y expectativas sin fundamento antes de incorporarlas al repositorio.

Una IA puede acelerar tareas repetitivas y sugerir casos olvidados. La responsabilidad de decidir si el resultado representa bien el requisito sigue en la revisión humana del cambio y en la ejecución real del proyecto. Si una prueba nueva falla, investiga la causa; no la borres solo para recuperar un indicador verde. Si todas pasan, pregunta qué defecto seguiría pasando inadvertido.

Si necesitas un ejemplo concreto de escritura de pruebas para un comercio electrónico, consulta nuestra guía sobre tests automáticos con IA en una tienda online. Aquella guía explica la preparación de casos; esta pieza se concentra en cómo evaluar su capacidad de detectar errores.

Fuentes y agradecimientos

• JaCoCo, Coverage Counters: agradecemos sus definiciones de cobertura de instrucciones, ramas y líneas.
• PIT Mutation Testing, explicación y uso y guía de inicio: agradecemos su explicación de las pruebas de mutación. Estos proyectos no han revisado ni avalado los ejemplos de Gaia.
• Konstantinou, Degiovanni y Papadakis, estudio de oráculos generados con modelos: agradecemos su investigación sobre el alcance de estos enfoques en repositorios Java; sus resultados no prueban la calidad de todas las herramientas.