Pruebas generadas por IA: cobertura no es confianza

Pedirle pruebas al modelo es probablemente el uso de IA con mejor aceptación en cualquier equipo: a nadie le gusta escribir pruebas para código legado, la cobertura sube rápido y el gráfico queda lindo. Es también donde la ilusión de calidad se instala con más facilidad.

La cobertura mide ejecución, no verificación

La cobertura responde una sola pregunta: ¿esta línea se ejecutó durante la suite? No responde si alguien verificó el resultado.

Es trivial escribir una prueba que ejecuta cien líneas y no afirma casi nada. Si el modelo genera cien pruebas así, tendrás 90% de cobertura y una suite que sigue en verde después de un cambio que rompió el comportamiento.

La pregunta útil no es "¿cuánto del código se cubrió?", es "si rompo este comportamiento a propósito, ¿falla alguna prueba?".

La prueba generada a partir del código hereda el bug

Ese es el problema estructural, y no se resuelve con un mejor prompt.

Cuando le das la implementación al modelo y le pides la prueba, describe lo que el código hace. Si la regla de negocio está mal implementada, la prueba generada pasa a proteger el error. Peor: a partir de ahí, corregir el bug rompe la prueba, y alguien va a "arreglar la prueba".

La alternativa es generar la prueba a partir de la especificación, del ticket, de la regla escrita, y recién después correrla contra la implementación. Cuando ambas discrepan, aprendiste algo. Es el espíritu del TDD, con el orden preservado.

Dónde ayuda de verdad la generación automática

Tres casos con retorno claro:

• Código legado sin ninguna cobertura. Aquí incluso una prueba de caracterización, que solo congela el comportamiento actual, tiene valor: es una red antes de refactorizar.
• Casos borde que nadie recuerda. Pedir la lista de entradas límite (vacío, nulo, negativo, unicode, límites numéricos) es donde el modelo más rinde.
• Mesetas de cobertura. Investigación presentada en ICSE 2023 mostró que usar un LLM para destrabar la generación de pruebas basada en búsqueda ayuda justamente cuando la técnica automática se estanca, que es el punto donde suele detenerse sola.

Vigila la flakiness

Un volumen grande de pruebas generadas aumenta el riesgo de pruebas inestables, y una prueba inestable cuesta más de lo que parece. La ingeniería de Google publicó que cerca del 1,5% de sus pruebas son flaky, y que consumen tiempo y confianza de forma desproporcionada.

El efecto práctico es conocido: cuando el rojo se vuelve ruido, el equipo deja de mirar. Una suite con muchas pruebas inestables es peor que una suite más chica y confiable.

Regla simple: una prueba que falla de forma intermitente sale de la barrera de bloqueo el mismo día, se vuelve un ítem de corrección, y solo regresa cuando sea determinista.

El tamaño de la prueba importa más que la cantidad

La práctica de pruebas de Google organiza la suite por tamaño y no por capa teórica: las pruebas pequeñas corren en un proceso, sin red ni disco; las medianas pueden usar localhost; las grandes pueden usar recursos externos. El objetivo es previsibilidad y velocidad.

Cuando la IA genera pruebas en volumen, tiende a producir pruebas medianas y grandes disfrazadas de unitarias, porque el modelo no sabe qué dependencias consideras caras. Conviene revisarlo explícitamente: si tu suite unitaria se volvió lenta tras la adopción, ese es el motivo.

Cómo verificar que la suite tiene dientes

Un ejercicio barato y revelador: toma tres reglas de negocio importantes, rompe cada una a propósito en el código y corre la suite. Si nada se pone en rojo, la cobertura no está protegiendo nada.

Esta es una versión manual y pobre de las pruebas de mutación, y alcanza para decidir dónde invertir. Si quieres ir más lejos, hay herramientas que automatizan la idea, pero empieza por el ejercicio manual: cuesta una hora y suele cambiar la conversación sobre metas de cobertura.

Qué significa esto para tu equipo

Deja de usar el porcentaje de cobertura como meta y úsalo solo como alerta cuando baje. Adopta el ejercicio de las tres reglas rotas una vez por trimestre.

Al generar pruebas con IA, genéralas a partir de la regla escrita y no del código, siempre que la regla exista. Y cuando la prueba caracterice comportamiento legado, márcalo en el nombre del archivo: quien venga después necesita saber que esa prueba describe el comportamiento actual, no el deseado.