AI-Assisted Test Generation
AI-Assisted Test Generation es la práctica de utilizar sistemas de IA para proponer o modificar tests, fixtures y casos de prueba que aporten evidencia sobre un comportamiento de software. El agente puede acelerar la elaboración de escenarios y su adaptación a convenciones existentes. La utilidad de esa contribución depende de qué expectativa expresa cada test, qué comportamiento observa y qué errores podría detectar.
Generar tests no equivale a realizar toda la actividad de testing, ni a verificar un cambio. Testing incluye decisiones sobre riesgos, estrategias, entornos e interpretación de resultados que exceden producir archivos. La verificación de una tarea necesita evidencia pertinente a sus expectativas concretas. Una suite generada que pasa puede aportar información sin demostrar que la implementación responde a la necesidad real.
Elegir qué necesita evidencia
Antes de generar código de prueba interesa comprender el comportamiento que se quiere proteger. Repository Exploration and Task Framing ayuda a localizar contratos y riesgos; Specification-Assisted Development puede conservar expectativas acordadas. El agente debería partir de esas referencias, además de leer la implementación. Si toma el resultado actual como única definición de lo correcto, puede fijar un defecto como comportamiento esperado.
El nivel de esfuerzo debe ser proporcional al cambio. Una regla con consecuencias persistentes puede necesitar casos de borde y errores; una corrección trivial de texto quizá no necesite tests nuevos. Agregar pruebas que solo reflejan una edición reversible no aporta necesariamente valor. La pregunta útil es qué incertidumbre relevante reduce cada comprobación y cuánto cuesta mantenerla.
El agente puede proponer vacíos de cobertura, pero “no hay un test para esta línea” no basta como justificación. Puede existir cobertura por otro recorrido o ser más importante una condición de negocio no representada en el código nuevo. Conviene relacionar escenarios con fallos posibles y resultados observables, en vez de optimizar el número de tests o una cifra de cobertura aislada.
El problema del resultado esperado
Un test necesita un criterio para distinguir un resultado válido de uno incorrecto: su oráculo. Si implementación y test provienen de la misma interpretación errónea, pueden concordar perfectamente. Pedir al mismo agente que escriba el test después de generar el código no crea por sí solo una referencia independiente. El problema existe aunque ambas piezas sean legibles y estén bien organizadas.
La expectativa puede derivarse de un contrato aceptado, un ejemplo validado con responsables del dominio o una propiedad explícita del sistema. El agente debe conservar esa procedencia cuando sea relevante. Un caso histórico observado sirve como evidencia de comportamiento, pero no demuestra que ese comportamiento deba mantenerse. Si hay desacuerdo entre la necesidad y el resultado actual, corresponde resolverlo antes de consolidar la aserción.
Supongamos una función de descuentos donde el código aplica el porcentaje antes de sumar un cargo. Un test generado copiando esa secuencia confirmará la implementación. Para decidir si está bien, hace falta conocer qué importe admite el descuento. La generación ayuda a expresar el caso una vez resuelta esa regla; no autoriza al modelo a definir la política comercial mediante el valor esperado.
Qué puede producir el agente
La asistencia puede generar tests unitarios para una regla localizada, pruebas de integración entre componentes o regresiones para un defecto identificado. También puede construir fixtures, datos de borde y casos que ejerciten rechazos. Estas contribuciones tienen alcances diferentes. Una prueba unitaria con dobles no demuestra que la configuración de persistencia real interprete del mismo modo los datos.
Las fixtures deben representar estados posibles y evitar información sensible innecesaria. Un conjunto de datos mínimo facilita entender qué condición causa el resultado. Datos excesivos o generados sin criterio pueden ocultar supuestos inválidos. Si un fixture omite una restricción del sistema real, el test puede pasar para una situación que nunca ocurriría o dejar de cubrir la que interesa.
El agente también puede adaptar tests a una interfaz modificada. Debe separar ajustes mecánicos de cambios en expectativas. Renombrar una propiedad no debería convertirse silenciosamente en relajar una aserción. Si la nueva semántica requiere actualizar resultados esperados, esa relación necesita explicación para que el revisor pueda distinguir evolución legítima de una prueba debilitada para obtener verde.
Casos negativos y límites
El sesgo hacia el happy path produce ejemplos donde todo existe, el estado es válido y ninguna dependencia falla. Un agente puede ampliar esa visión buscando entradas ausentes, conflictos, límites numéricos o respuestas externas inesperadas. No conviene enumerar combinaciones infinitas: interesan las condiciones que cambian decisiones o efectos relevantes de la tarea.
Los casos negativos deben afirmar algo útil. Comprobar solamente que “hay un error” puede permitir que falle una ruta completamente distinta de la esperada. También importa evitar expectativas demasiado específicas sobre detalles incidentales, como el texto completo de una excepción interna cuando el contrato solo garantiza una categoría pública. El equilibrio depende del comportamiento que realmente se desea conservar.
Las fronteras temporales, de orden y de estado merecen atención cuando participan en el cambio. Un test que depende del reloj real o de una ejecución casualmente serial puede resultar inestable. El agente puede sugerir puntos de control explícitos y datos deterministas, sin introducir una infraestructura genérica de pruebas que la tarea no necesita.
Acoplamiento a la implementación
Una prueba que reproduce la estructura interna del código puede romperse ante una refactorización correcta y pasar frente a un error compartido. El artículo de Google sobre change-detector tests ilustra ese problema mediante aserciones que siguen la implementación sin establecer comportamiento útil. El riesgo es especialmente relevante cuando el agente recibe el código como principal fuente para generar aserciones.
Los dobles y mocks pueden delimitar dependencias, pero un exceso puede hacer que el test solo compruebe interacciones decididas por el mismo autor. Verificar una llamada tiene sentido si esa interacción es parte del contrato importante. No lo tiene automáticamente porque la herramienta pueda observarla. La ausencia de fallos no informa sobre una integración que fue sustituida por completo.
Testability trata las condiciones que permiten observar y controlar el sistema para probarlo. La generación asistida puede revelar dificultades existentes, como responsabilidades mezcladas o dependencias inaccesibles. Esa observación no autoriza a rediseñar el módulo entero dentro de una tarea pequeña. Se puede proponer una mejora acotada y explicar qué evidencia habilitaría.
Regresiones y reproducción
Para un defecto concreto puede ser útil mostrar que el escenario falla antes de la corrección y pasa después, siempre que el entorno y el costo lo permitan. Eso conecta el test con el síntoma y reduce el riesgo de una prueba que nunca ejercita el problema. No constituye una obligación de fabricar una fase roja para cada cambio editorial o modificación de bajo impacto.
La reproducción necesita preservar condiciones relevantes. Si el fallo aparece con dos operaciones concurrentes, una prueba secuencial puede no representar el defecto. Si depende de serialización o configuración, reemplazar esa frontera por un stub puede ocultarlo. El agente debería explicar qué parte de la situación original está reproduciendo y qué parte permanece fuera del entorno disponible.
La investigación del defecto se desarrolla en AI-Assisted Implementation and Change Maintenance. Generar la regresión es una contribución a ese trabajo, no una confirmación automática de la causa propuesta. Un test puede exhibir el síntoma sin discriminar entre todas las explicaciones posibles.
Evitar test gaming y falsa confianza
Test gaming aparece cuando se optimiza pasar una comprobación sin conservar la intención que debía proteger. Puede incluir eliminar aserciones difíciles, sustituir resultados por constantes o aceptar cualquier salida. No requiere intención maliciosa: un agente orientado a resolver fallos puede interpretar que toda prueba roja debe adaptarse a su implementación.
La revisión debe observar tanto cambios en producción como modificaciones de expectativas. Si una aserción desaparece, interesa saber si dejó de pertenecer al contrato o si se está ocultando un problema. Marcar un test como omitido también cambia la evidencia disponible. Un resumen que solo dice “suite verde” pierde esa diferencia y puede inducir al equipo a aceptar una confianza injustificada.
El número de pruebas generadas tampoco mide independencia. Muchas variaciones con la misma premisa incorrecta aportan poca protección frente a ese error. Es preferible un conjunto pequeño de casos con razones claras que una gran colección de ejemplos redundantes. La asistencia ayuda a proponer diversidad; las razones de selección siguen necesitando juicio de ingeniería.
Ejecución e interpretación
Una prueba intermitente requiere analizar qué variación la afecta. Repetirla hasta obtener verde puede ocultar una dependencia temporal o de estado que el caso debía exponer. El agente puede comparar ejecuciones y reducir condiciones, sin eliminar la aserción problemática como primera respuesta. Si la inestabilidad pertenece al entorno y todavía no está resuelta, debe registrarse como una limitación de la evidencia disponible.
El agente debe indicar qué tests ejecutó realmente, sobre qué revisión y con qué resultado. Generar un archivo de test no demuestra que compile ni que la suite lo descubra. Un comando exitoso puede haber ejecutado un subconjunto diferente del esperado. Las salidas de herramientas necesitan interpretarse en relación con la tarea, incluyendo pruebas omitidas y limitaciones del entorno.
Los Development Context and Execution Records permiten conservar comandos, resultados y dudas pendientes. No hacen falta transcripciones enormes para una comprobación sencilla; sí suficiente información para no confundir una ejecución prevista con una realizada. Si una dependencia impidió correr la integración, la limitación debe acompañar la entrega aunque los tests unitarios estén verdes.
Una falla durante la ejecución puede orientar una revisión de la implementación, del test o del supuesto que ambos comparten. Cambiar inmediatamente la aserción para aceptar el resultado observado elimina esa oportunidad. El agente puede proponer hipótesis y experimentos, mientras una expectativa de negocio incierta se consulta con quien tiene autoridad para resolverla.
Colaboración, revisión y alcance
Las personas pueden aportar casos que no aparecen en el código y revisar qué resultados son aceptables. El agente puede sistematizarlos, detectar inconsistencias y ejecutar comprobaciones dentro de sus límites. Esa colaboración distribuye trabajo sin convertir la generación automática en una autoridad sobre el contrato. Tampoco obliga a utilizar varios agentes o herramientas especializadas en toda tarea.
AI-Assisted Code Review puede examinar si los tests nuevos cubren el riesgo que motivó el cambio y si sus expectativas están justificadas. La revisión aporta evidencia adicional, pero tampoco equivale a verificación completa. La distinción entre generación, testing y verificación debe permanecer visible al comunicar resultados.
La salida útil de esta práctica incluye pruebas pertinentes y una explicación honesta de su alcance. No es una promesa de ausencia de defectos. Cuando el agente dice que terminó, corresponde distinguir el artefacto producido, las comprobaciones realizadas y lo que todavía necesita evaluación. generated-code-verification desarrolla ese juicio sobre el cambio; coding-agent-failure-modes-and-recovery conecta test gaming y false completion con su diagnóstico. La verificación no se reemplaza acumulando tests.
Fuentes
- Google Testing Blog: Change-Detector Tests Considered Harmful, 2015: ejemplo del problema de reflejar implementación en vez de proteger comportamiento.