Meta mejora las pruebas unitarias automatizadas con modelos de lenguaje de gran escala

TestGen-LLM de Meta para mejorar las pruebas unitarias automatizadas

• La herramienta TestGen-LLM, desarrollada por Meta, utiliza modelos de lenguaje de gran escala (LLM) para mejorar automáticamente pruebas escritas por humanos.
• Las clases de prueba generadas por TestGen-LLM superan con éxito una serie de filtros que garantizan mejoras medibles frente a la suite de pruebas original, resolviendo problemas de alucinación de LLM.
• Se describe el despliegue de TestGen-LLM en los test-a-thons de Meta para las plataformas de Instagram y Facebook.

Desempeño de TestGen-LLM

• En la evaluación de los productos Reels y Stories de Instagram, el 75% de los casos de prueba generados por TestGen-LLM se compilaron correctamente, el 57% se ejecutó con fiabilidad y el 25% aumentó la cobertura.
• En los test-a-thons de Instagram y Facebook de Meta, TestGen-LLM mejoró el 11.5% de todas las clases donde se aplicó, y los ingenieros de software de Meta aceptaron el 73% de las recomendaciones para el despliegue.
• Este es el primer informe de despliegue industrial a gran escala de código generado por LLM con este tipo de garantía de mejora de código.

Opinión de GN⁺

• TestGen-LLM puede ser una herramienta con potencial de innovación en la automatización y mejora de la calidad del software de pruebas, al lograr mejoras al aprovechar modelos de lenguaje de gran escala para mejorar pruebas existentes.
• Esta herramienta contribuye de manera importante a la comunidad de ingeniería de software al aumentar la cobertura de pruebas en un entorno industrial y generar casos de prueba fiables.
• La aplicación exitosa en los test-a-thons de Meta muestra que TestGen-LLM puede integrarse al desarrollo de productos reales, lo que puede mejorar significativamente la eficiencia y la estabilidad del desarrollo de software.

[GN⁺]

Comentario de Hacker News

• En una gran compañía de seguros, los gerentes establecieron como objetivo una cobertura de pruebas del 80 % para toda la base de código. En respuesta, los desarrolladores empezaron a escribir pruebas unitarias simples para los getters y setters de DTO de Java para llegar a esa meta. Como desarrollador joven, esta experiencia me enseñó que centrarse solo en KPIs puede inducir comportamientos que no se alinean con el objetivo real. Habría impactado mejor en la calidad del software un puñado de escenarios de prueba E2E bien diseñados.
• El problema de las pruebas generadas por LLM es que tienden a "aprobar" comportamientos con bugs. Esto pasa especialmente cuando la cobertura de pruebas de la base de código es baja. Al escribir pruebas nuevas de forma manual, hay alguien que puede decidir si el problema está en que el sistema es tonto o en que la prueba está mal. Al menos, este tipo de pruebas debería mantenerse en una carpeta especial y tratarse con un nivel adecuado de sospecha.
• Al leer el PDF, parece que esto solo genera pruebas que pasan repetidamente, sin variación. El objetivo principal es crear un conjunto de pruebas de regresión que fije el comportamiento del código existente. Esto no reemplaza las pruebas escritas por desarrolladores; se asume que las pruebas de los desarrolladores conocen los requisitos funcionales.
• En una empresa donde trabajé hace casi 20 años se probó AgitarOne. Prometía generar automáticamente casos de prueba para código Java para ayudar a explorar su comportamiento. Pero Agitar también podía generar pruebas que pasaban automáticamente, y se podían usar como suite de regresión. A nivel personal, eso no me gustó. Los gerentes pensaron que, al subir la cobertura de pruebas, la calidad también mejoraba. Me intriga cuán mejor sea el enfoque con LLM frente a Agitar.
• Escribir pruebas suele ser una de las mejores formas de juzgar la calidad del código. Si las pruebas son complejas o cuesta alcanzar cobertura, probablemente el código bajo prueba necesite mejoras.
• En unlogged.io durante un tiempo nos enfocamos en generar automáticamente pruebas junit. Ese enfoque no prosperó por varias razones: 1) demasiados códigos de pruebas generadas que los desarrolladores no quieren mantener, 2) pruebas generadas que no simulan escenarios del mundo real, 3) cobertura de código como métrica de vanidad. Actualmente, nos enfocamos en ofrecer pruebas de replay no-code que simulan todos los escenarios de producción únicos. Por cierto, soy el fundador de unlogged.io.
• Por el contrario, quiero tomar el enfoque opuesto. Quisiera ingresar criterios de aceptación, generar pruebas que los validen, y luego hacer que solo se genere el código que las pase. Con Copilot a veces se puede llegar más o menos a eso de forma limitada, pero me pregunto por qué casi no hay quien se enfoque en este enfoque.
• TestGen-LLM es una rareza. Creo que puede usarse como primer paso para refactorizar o reescribir, pero el énfasis en la cobertura de código en el paper se siente totalmente descabellado. Si una organización ya está loca de exigir alta cobertura, puede ser útil, pero TestGen-LLM no mejorará el código del proyecto de ninguna forma y aumentará la fricción relacionada con la implementación de mejoras reales. Un TestGen-LLM que filtra basura de LLM basándose en errores de compilación y pruebas fallidas sería mucho más útil si generara pruebas de casos borde que a veces pasarían y a veces no. Dado que no hay ejemplos de pruebas generadas en el paper, sospecho que se ven tan amateurs como el resto del código generado por LLM que he visto.
• Me pregunto cuánto costará mantener en el futuro un corpus masivo de pruebas generadas automáticamente. Además de generar casos, se tendría que ofrecer una forma automatizada de actualizarlos.
• Es interesante, lo admito, que personal de Meta haya publicado un paper de 12 páginas para promover IA para desarrolladores. Incluso usó diagramas de Sankey. Tal vez me equivoque, pero si se publica así debería haber información reproducible. Meta necesita datos para entrenar. Quizá por eso publicó algo.
• En la evaluación de los productos Reels y Stories de Instagram, el 75 % de los casos de prueba de TestGen-LLM quedaron correctamente construidos, el 57 % pasó de forma confiable y el 25 % aumentó la cobertura. No parece que el resultado sea tan bueno.