Eficacia de las pruebas unitarias generadas por modelos de lenguaje

La calidad no se mide solo por cuánto código se ejecuta

Las pruebas unitarias generadas por modelos de lenguaje pueden acelerar la creación de una primera batería de comprobaciones, pero su utilidad depende de algo más que la cantidad de código alcanzado. Una prueba puede compilar y ejecutar muchas líneas sin detectar un defecto; también puede pasar porque sus aserciones sean demasiado débiles o porque reproduzca el mismo supuesto erróneo que el código que pretende verificar. Por ello, evaluar pruebas generadas requiere considerar conjuntamente su validez, capacidad de detección, cobertura y mantenibilidad.

La tesis práctica es sencilla: la cobertura estructural sirve para localizar zonas poco ejercitadas, pero no demuestra que las pruebas distingan el comportamiento correcto del defectuoso. Para valorar ese poder discriminatorio hay que observar, entre otros factores, si las pruebas compilan, si ejecutan ramas relevantes, si fallan ante cambios defectuosos y si sus aserciones expresan con precisión el contrato del código. La generación debe tratarse como una hipótesis que se somete a verificación, no como garantía de calidad.

Qué se está evaluando

Conviene separar tres objetos que a menudo se confunden: el modelo que propone el código de prueba, el método de prompting que orienta esa generación y el conjunto de pruebas resultante. Si cambia el prompt, puede cambiar la cobertura o la legibilidad incluso usando el mismo modelo. Si cambia el modelo, las diferencias pueden reflejar tanto su capacidad como la manera en que se le suministró el contexto. Una comparación útil mantiene constantes el proyecto, las instrucciones, el entorno de ejecución y los criterios de puntuación, y modifica una variable cada vez.

La unidad de análisis también importa. Una prueba individual puede ser correcta, pero redundante dentro de una suite; una suite puede alcanzar alta cobertura con pocos casos útiles; y un conjunto de pruebas puede resultar difícil de mantener aunque detecte fallos. Por tanto, no basta con preguntar «¿cuántas pruebas se generaron?». Hay que preguntar qué comportamiento cubren, qué fallos revelan y qué coste futuro añaden al mantenimiento.

Del prompt a una evaluación reproducible

Especificar el contrato antes de solicitar casos

La calidad de las entradas generadas depende en parte de la precisión con que se describa el comportamiento esperado. Antes de pedir pruebas, conviene identificar la firma del método, sus precondiciones, sus invariantes, los rangos válidos y la respuesta esperada ante entradas inválidas. Cuando la especificación sea ambigua, el modelo puede convertir una interpretación plausible en una aserción que parezca razonable, pero no represente la intención del sistema.

Un prompt técnico puede pedir categorías explícitas: casos normales, valores extremos, entradas inválidas y situaciones de escala. Para una función que acepta un entero dentro de un intervalo cerrado, por ejemplo, no basta con solicitar «pruebas exhaustivas». Es más verificable pedir el mínimo, el máximo, los valores inmediatamente inferior y superior, y entradas fuera del rango; además, hay que especificar qué resultado o excepción corresponde a cada caso. Para datos estructurados, conviene añadir valores nulos, campos ausentes, formatos malformados, duplicados y combinaciones que puedan activar ramas condicionales.

La instrucción también debe limitar el alcance. Puede exigir pruebas independientes, nombres descriptivos, aserciones sobre resultados observables y ausencia de cambios en el código de producción. Si el contexto incluye clases auxiliares o convenciones del proyecto, deben aportarse para evitar que la generación invente dependencias o use patrones incompatibles con el entorno.

Validar compilación, cobertura y detección de fallos

Un flujo de evaluación comienza por compilar y ejecutar la suite en un entorno reproducible. Las pruebas que no compilan no ofrecen cobertura útil; las que fallan antes de llegar a las aserciones pueden indicar errores de configuración, dependencias o generación. Después se revisan cobertura de líneas y ramas para detectar rutas no ejercitadas. Estas métricas ayudan a describir alcance, pero no miden directamente la capacidad de encontrar errores.

Las pruebas de mutación aportan una comprobación más exigente: se introducen cambios pequeños y deliberadamente defectuosos en el programa, y se observa si la suite falla. Si una mutación cambia una comparación, altera un valor límite o elimina una condición y las pruebas siguen pasando, es posible que el caso relevante falte o que la aserción sea insuficiente. El resultado debe interpretarse con cautela: una mutación que no se detecta puede ser equivalente en el contexto evaluado, y una tasa elevada de detección no garantiza que estén cubiertos todos los requisitos.

La revisión técnica debe incluir también calidad de las aserciones, excepciones esperadas, dependencia entre pruebas, duplicación y claridad de los nombres. Una prueba que comprueba solo que «no se produce una excepción» puede ser válida para una condición concreta, pero no sustituye la comprobación del resultado semántico cuando este es lo que define el contrato. El criterio no es maximizar el número de aserciones, sino hacer que cada una detecte una desviación relevante sin fijar detalles internos innecesarios.

Comparar métodos sin confundir cobertura y eficacia

Qué indica la evidencia disponible

Un estudio a gran escala evaluó 216.300 pruebas para 690 clases Java y comparó cuatro modelos y cinco técnicas de prompting con EvoSuite. Analizó corrección, legibilidad, cobertura y detección de errores. Sus resultados muestran que el diseño de la instrucción influye significativamente: Chain-of-Thought y Guided Tree-of-Thought estuvieron entre los enfoques más eficaces y, en algunos conjuntos, alcanzaron o superaron la cobertura de EvoSuite [1]. Esto no implica que una técnica sea óptima para cualquier repositorio; sí justifica probar estrategias de prompting bajo el mismo protocolo, en vez de asumir que una petición genérica producirá una suite suficiente.

La investigación sobre valores límite ofrece otra perspectiva. En el estudio correspondiente, las entradas generadas por LLM se ejecutaron contra versiones mutantes con seis tipos de fallos introducidos; la evaluación registró cobertura y detección mediante Gcov. El método encontró utilidad para fallos comunes de frontera, pero tuvo dificultades con entradas complejas o poco habituales [2]. La consecuencia es concreta: enumerar límites en el prompt mejora la especificidad, pero hay que comprobar si esos casos realmente separan el comportamiento correcto del defectuoso mediante mutaciones.

En una evaluación de flujo de trabajo, una organización podría comparar generación directa, instrucciones guiadas por categorías y técnicas de razonamiento estructurado, manteniendo idénticos el código, el conjunto de mutaciones y los criterios de compilación. AI Plaza (https://aiplaza.app) aparece aquí solo como ejemplo de un escritorio donde el mismo protocolo puede lanzarse contra más de un modelo. No es una medición del producto ni una afirmación de que un catálogo concreto ya liste esos identificadores. La observación pertinente no es qué modelo parece más convincente al leer su respuesta, sino qué resultados reproducibles obtiene bajo las mismas condiciones de prueba.

Un cuadro de evaluación equilibrado

Estas dimensiones no deberían reducirse automáticamente a una única puntuación. Si se necesita un indicador agregado para comparar versiones, deben conservarse los resultados desglosados y documentarse cómo se ponderan. De lo contrario, una mejora aparente en cobertura podría ocultar más pruebas frágiles o menos detección de mutaciones.

Integrar la evaluación en el ciclo de desarrollo

De la generación puntual al control continuo

En equipos de desarrollo, una generación aislada aporta evidencia limitada. Un marco industrial de evaluación continua descrito en la literatura combina métricas técnicas —incluidas cobertura y análisis estático— con mantenibilidad y valoración experta, y menciona herramientas como SonarQube [3]. El valor del enfoque reside en comparar iteraciones del generador y detectar regresiones, no solo en puntuar una respuesta concreta. En la práctica, cada cambio en el modelo, el prompt o las plantillas puede someterse a una batería de referencia con versiones conocidas del código y mutaciones reproducibles.

La integración en el ciclo de vida puede organizarse como una secuencia automatizada: generar candidatos; compilar; ejecutar pruebas; medir cobertura; aplicar mutaciones; analizar duplicados y estilo; y publicar un informe comparable con ejecuciones anteriores. Los resultados que no superen los controles pueden descartarse o enviarse a revisión de ingeniería. La intervención humana conserva una función específica: validar que las aserciones reflejen requisitos y no una interpretación accidental. No sustituye los controles automatizados ni equivale a una campaña de pruebas manual; valida la semántica de lo que el generador afirma comprobar.

Consecuencias para la ingeniería de software

La métrica debe seguir al riesgo del componente

A largo plazo, las pruebas generadas pueden hacer más barata la exploración de comportamientos y ampliar la cobertura de componentes con especificaciones claras. Sin embargo, la facilidad de generación también puede incrementar suites voluminosas y redundantes. Si se optimiza solo el volumen o la cobertura, el sistema puede producir más código de prueba sin aumentar la confianza en el software. La dirección técnica adecuada es vincular los criterios de aceptación al riesgo: en lógica con numerosos límites, priorizar casos adyacentes y mutaciones; en componentes con validación de datos, priorizar entradas inválidas y excepciones; en algoritmos con varias ramas, observar cobertura y detección de alteraciones relevantes.

También será necesario vigilar la estabilidad entre ejecuciones. La reproducibilidad exige fijar versiones del código, dependencias, prompts y parámetros de generación, además de conservar las salidas evaluadas. Así se podrá determinar si una mejora procede de cambios reales en el generador o de variaciones en el contexto y el entorno. La investigación disponible respalda una conclusión operativa prudente: los modelos pueden contribuir a generar pruebas útiles, pero su eficacia debe medirse con varias señales, especialmente con evidencia de detección de defectos y calidad mantenible, no inferirse de una cobertura elevada por sí sola.

Referencias

[1] https://arxiv.org/abs/2407.00225 [2] https://arxiv.org/abs/2501.14465 [3] https://arxiv.org/pdf/2504.18985