Implementan por primera vez como código abierto el TestGen-LLM de Meta

• En el artículo publicado por Meta en febrero, "Automated Unit Test Improvement using Large Language Models at Meta", se presentó una herramienta llamada TestGen-LLM
• El objetivo de esta herramienta es aumentar la cobertura de pruebas de forma totalmente automatizada, garantizando una mejora respecto a la base de código existente
• Como Meta no publicó el código de TestGen-LLM, decidieron implementarlo directamente como parte del proyecto open source Cover-Agent
• Aquí comparten el proceso de implementación, lo que descubrieron y los problemas que enfrentaron al usar TestGen-LLM en bases de código reales

Criterios para la generación automática de pruebas

• La generación automática de pruebas usando IA generativa no es algo nuevo
• La mayoría de los LLM son hábiles generando código y también pueden generar pruebas
• El problema más común con el que se topan los desarrolladores al generar pruebas con LLM es que la mayoría de las pruebas generadas no funcionan o no aportan valor
• Para superar esto, los autores de TestGen-LLM proponen los siguientes criterios para las pruebas unitarias de regresión:
  1. ¿La prueba compila y se ejecuta correctamente?
  2. ¿La prueba aumenta la cobertura de código?
• Si no se puede responder estas dos preguntas básicas, no hay razón para aceptar ni analizar las pruebas generadas por el LLM
• Si pasa estas preguntas, entonces se realiza una revisión manual posterior
  • ¿Qué tan bien está escrita la prueba?
  • ¿Cuánto valor real puede agregar?
  • ¿Cumple con requisitos adicionales?

Enfoque de TestGen-LLM y resultados reportados

• TestGen-LLM (y Cover-Agent) se ejecuta de forma completamente headless
• Primero genera muchas pruebas, luego filtra las que no compilan o no se ejecutan, descarta las que no pasan y elimina las que no aumentan la cobertura de código
• En casos muy controlados, la proporción entre pruebas generadas y pruebas que superan todas las etapas es de 1:4, y en escenarios reales los autores de Meta reportan una proporción de 1:20
• Después del proceso automatizado, Meta hace que revisores humanos acepten o rechacen las pruebas
• Los autores del artículo dicen haber visto una tasa promedio de aceptación de 1:2, con un 73% de aceptación en el mejor de los casos
• Como se describe en el artículo, la herramienta TestGen-LLM genera en cada ejecución una sola prueba que se agrega al conjunto de pruebas existente previamente escrito por desarrolladores expertos
• Además, no necesariamente genera una prueba para cada conjunto de pruebas dado

Implementación de Cover-Agent

• Cover-Agent v0.1 se implementó de la siguiente manera:
  1. Recibir la entrada del usuario (archivo fuente objetivo de prueba, conjunto de pruebas existente a mejorar, reporte de cobertura, comandos para compilar y ejecutar el conjunto de pruebas, objetivo de cobertura de código y número máximo de iteraciones, contexto adicional y opciones de prompt)
  2. Generar más pruebas con el mismo estilo
  3. Validar esas pruebas usando el entorno de ejecución (si compilan y pasan)
  4. Revisar métricas como el aumento en la cobertura de código para verificar si la prueba aporta valor
  5. Actualizar el conjunto de pruebas existente y el reporte de cobertura
  6. Repetir hasta que el código alcance el criterio definido (se llegue al umbral de cobertura de código o al número máximo de iteraciones)

Problemas enfrentados al implementar y revisar TestGen-LLM

• En los ejemplos presentados en el artículo, se usa Kotlin para escribir pruebas, donde los espacios en blanco no son importantes
• En cambio, en lenguajes como Python, las tabulaciones y espacios no solo importan, sino que son esenciales para el parser
• Modelos menos sofisticados como GPT 3.5, incluso con prompts explícitos, no devuelven de forma consistente código con la indentación correcta
• Un ejemplo de esto son las clases de prueba escritas en Python, donde cada función de prueba debe estar indentada
• Esto tuvo que considerarse a lo largo de todo el ciclo de vida de desarrollo, agregando más complejidad alrededor de la biblioteca de preprocesamiento
• Todavía hay mucho por mejorar para hacer a Cover-Agent robusto en estos escenarios
• Como parte del flujo de Cover-Agent, agregaron la capacidad de que el usuario proporcione entradas o instrucciones adicionales al LLM (opción --additional-instructions)
• Esto permite a los desarrolladores personalizar Cover-Agent con información adicional específica del proyecto
• Por ejemplo, pueden usar estas instrucciones para orientar a Cover-Agent a crear un conjunto de pruebas rico en edge cases significativos
• Coincidiendo con la tendencia general de una mayor adopción de Retrieval-Augmented Generation (RAG) en aplicaciones basadas en IA, confirmaron que contar con más contexto junto con la generación de pruebas unitarias permite pruebas de mayor calidad y una mayor tasa de éxito
• Para usuarios que quieran agregar manualmente bibliotecas adicionales o documentos de diseño basados en texto como contexto para el LLM con el fin de mejorar el proceso de generación de pruebas, ofrecen la opción --included-files
• El código complejo que requiere múltiples iteraciones representa otro desafío para los LLM
• A medida que se generaban pruebas fallidas (o que no aportaban valor), empezaron a detectar un patrón en el que se proponían repetidamente las mismas pruebas no aceptadas en iteraciones posteriores
• Para resolverlo, agregaron una sección de "pruebas fallidas" al prompt para transmitir esa retroalimentación al LLM y evitar que repita pruebas que ya determinó que no puede usar (es decir, porque fallan o no incrementan suficientemente la cobertura)
• Otro problema que surgió durante todo este proceso es que no se pueden agregar imports de bibliotecas al ampliar un conjunto de pruebas existente
• Los desarrolladores a veces pueden ser miopes al usar un solo enfoque hacia un framework de testing dentro del proceso de generación de pruebas
• Además de muchos frameworks de mocking distintos, otras bibliotecas también pueden ayudar a lograr cobertura de pruebas
• Como el artículo de TestGen-LLM (y Cover-Agent) tiene como objetivo extender un conjunto de pruebas existente, reestructurar por completo toda una clase de pruebas queda fuera de alcance
• Esta es una limitación de la expansión de pruebas frente a la generación de pruebas, y planean abordarla en iteraciones futuras
• Es importante distinguir que, en el enfoque de TestGen-LLM, se requiere una revisión manual del desarrollador para cada prueba antes de proponer la siguiente
• En cambio, en Cover-Agent se generan, validan y proponen tantas pruebas como sea posible sin intervención manual a lo largo del proceso, hasta cumplir los requisitos de cobertura (o detenerse al alcanzar el máximo de iteraciones)
• Esto crea un enfoque no intrusivo para la generación automática de pruebas, que se ejecuta en segundo plano con IA para que el desarrollador pueda revisar todo el conjunto de pruebas de una sola vez al finalizar el proceso

Conclusión y planes a futuro

• Muchas personas (incluyéndome) están entusiasmadas con el artículo y la herramienta TestGen-LLM, pero en este post se habló de sus limitaciones
• Seguimos creyendo que todavía estamos en la era de los asistentes de IA, no de compañeros de equipo de IA que ejecuten flujos totalmente automatizados
• Al mismo tiempo, un flujo bien diseñado puede ayudar a los desarrolladores a generar automáticamente candidatos de prueba y aumentar la cobertura de código en mucho menos tiempo, algo que planean desarrollar y compartir en Cover-Agent
• Seguirán desarrollando métodos de vanguardia relacionados con el dominio de la generación de pruebas para integrarlos en el repositorio open source de Cover-Agent
• Esperan que cualquiera que esté interesado en la IA generativa para testing colabore y ayude a ampliar las capacidades de Cover-Agent, y también que este proyecto open source inspire a investigadores a explorar nuevas técnicas de generación de pruebas
• Agregaron una hoja de ruta de desarrollo al repositorio open source de Cover-Agent en GitHub, y les gustaría ver contribuciones al repositorio siguiendo esa hoja de ruta o ideas propias
• La visión de Cover-Agent es ejecutarse automáticamente en el futuro para todas las solicitudes pre/post-pull request y proponer automáticamente mejoras en pruebas de regresión validadas como funcionales y capaces de aumentar la cobertura de código
• Imaginan a Cover-Agent escaneando automáticamente la base de código y abriendo PRs con conjuntos de pruebas
• ¡Aprovechemos la IA para encargarnos con más eficiencia de las tareas que no nos gustan!