Presentamos Synbciatr: Un Nuevo Método para Repara Código de Pruebas

En el desarrollo de software, es super importante que las actualizaciones del código de prueba vayan de la mano con los cambios en el código de producción. Sin embargo, muchas veces, las actualizaciones de las pruebas se quedan atrás, lo que puede hacer que los proyectos no compilen correctamente o se enfrenten a otros problemas. Los métodos actuales pueden usar modelos de lenguaje para ayudar a arreglar pruebas que se han vuelto obsoletas por esas discrepancias, especialmente para problemas relacionados con la sintaxis. Pero, un reto es que la info necesaria para arreglar estas pruebas no siempre está disponible directamente, lo que hace difícil lograr arreglos precisos en proyectos grandes.

Este artículo presenta un nuevo enfoque llamado Synbciatr, que está diseñado para reparar automáticamente casos de prueba obsoletos. El método se centra en construir contextos relevantes de todo el repositorio de código para ayudar en el proceso de reparación.

#La Necesidad de Reparar Código de Prueba

Cuando se actualiza el software, puede cambiar varias partes del código, y las pruebas que verifican estos cambios también deben actualizarse. Si el código de prueba asociado no se actualiza junto con los cambios del código de producción, puede que no funcione correctamente, lo que lleva a errores.

Muchas técnicas existentes han intentado abordar la necesidad de actualizar el código de prueba. Generalmente, estas dependen de usar modelos de lenguaje, que pueden procesar código y sugerir arreglos. Pero estos modelos a menudo tienen dificultades con repositorios más grandes donde el contexto de lo que necesita ser arreglado no se identifica fácilmente.

#Los Desafíos en la Reparación de Pruebas

Cuando los desarrolladores reparan manualmente casos de prueba, recogen información sobre las partes relevantes del código que cambiaron. Sin embargo, al usar métodos automatizados, el contexto necesario para arreglar las pruebas no siempre es claro. Los métodos actuales suelen enfocarse solo en las partes específicas del código que cambiaron, dejando de lado contextos importantes.

Uno de los problemas más comunes es cuando cambia la firma de un método. Esto se refiere a los cambios en el nombre del método, el tipo de retorno o los tipos de sus parámetros. Tales cambios pueden llevar a errores de compilación si las pruebas relacionadas no se actualizan también. Además, simplemente introducir las firmas originales y nuevas en un modelo de lenguaje a menudo no lleva a arreglos efectivos porque falta el contexto correcto.

Para reparar estos casos con precisión, es crítico capturar y proporcionar el contexto adecuado, que llamamos Contextos Orientados a la Reparación de Pruebas (TROCtx).

#Introduciendo Synbciatr

Synbciatr ofrece una nueva forma de reparar automáticamente pruebas que se han vuelto obsoletas debido a cambios en las firmas de los métodos. Su objetivo principal es recopilar contexto relevante del repositorio de código y usarlo para informar al modelo de lenguaje en su tarea de reparación. Para lograr esto, se definen tres tipos de TROCtx: contextos de clase, contextos de uso y contextos de entorno.

#Tipos de Contextos

1. Contextos de Clase (ClassCtx) proporcionan información sobre las nuevas clases introducidas en la firma del método actualizado.
2. Contextos de Uso (UsageCtx) se enfocan en cómo se está llamando el método actualizado en todo el código.
3. Contextos de Entorno (EnvCtx) dan detalles sobre el entorno circundante en el que opera el método, incluyendo clases padre y código relacionado.

Cada uno de estos tipos de contexto juega un papel importante para asegurar que el modelo de lenguaje tenga suficiente información para reparar las pruebas con precisión.

#Cómo Funciona Synbciatr

El proceso que sigue Synbciatr involucra varios pasos clave. Primero, recolecta el TROCtx necesario de todo el repositorio de código mediante análisis estático, que implica examinar el código sin ejecutarlo. Usando una herramienta llamada Language Server, Synbciatr puede solicitar información sobre los diversos contextos.

#Recolección de Contextos

Durante la recolección de contextos, Synbciatr analiza los cambios realizados en el método en cuestión e identifica identificadores relevantes que corresponden a los nuevos y viejos parámetros del método. Después de identificarlos, Synbciatr solicita detalles del Language Server sobre estos identificadores.

#Reordenando Contextos

Después de recoger los contextos, Synbciatr usa algo llamado Neural Rerankers para priorizar qué contextos son los más relevantes para la tarea en cuestión. Esto se hace creando consultas basadas en el código de prueba original y usándolas para puntuar la relevancia de los contextos recopilados. Los contextos mejor puntuados se seleccionan para ser usados por el modelo de lenguaje.

#Generando el Prompt de Reparación

Una vez que se han reunido y priorizado los contextos relevantes, Synbciatr prepara un prompt completo para el modelo de lenguaje. Este prompt incluye la información necesaria, como los cambios realizados en el método, el código de prueba original y los TROCtx identificados. De esta manera, el modelo de lenguaje tiene todo el contexto que necesita para generar una versión reparada del caso de prueba.

#Evaluando la Efectividad de Synbciatr

Para ver qué tan bien funciona Synbciatr, se puso a prueba el método contra enfoques existentes. Se creó un conjunto de datos especial, que consistía en varios casos de prueba que se habían vuelto obsoletos debido a cambios en sus métodos asociados. Los principales objetivos eran ver cuán a menudo Synbciatr podía reparar con precisión pruebas y comparar su rendimiento contra otros dos métodos.

#Conjunto de Datos de Referencia

Se creó un conjunto de datos de referencia filtrando y refinando muestras existentes de proyectos populares de Java en GitHub. Después de limpiar el conjunto de datos, quedaron un total de 137 muestras, que eran diversas en sus tipos de cambios sintácticos.

#Métricas de Rendimiento

Se utilizaron varias métricas para evaluar el rendimiento de Synbciatr. Estas métricas incluyen:

• Tasa de Aprobación de Sintaxis (SPR): Esto mide cuántos de los casos de prueba generados pasan la validación de sintaxis.
• CodeBLEU: Esta métrica verifica la similitud de los casos de prueba generados con la verdad de base, que es la salida esperada.
• Coincidencia de Intención: Esta métrica evalúa si la intención detrás del caso de prueba original se preservó en la versión reparada.

Los resultados mostraron que Synbciatr superó tanto a los métodos de referencia en todas las métricas probadas, demostrando su capacidad para reparar con precisión pruebas obsoletas.

#Abordando el Impacto de TROCtx

Parte de la evaluación se centró en cuánto impacto tuvo la construcción de TROCtx en el rendimiento general de Synbciatr. Al comparar Synbciatr con Naivellm, que no usa TROCtx, fue evidente que la inclusión de contexto redujo significativamente el número de salidas incorrectas, conocidas como alucinaciones.

#Reducción de Alucinaciones

Las alucinaciones se refieren a instancias donde el modelo de lenguaje genera código que hace referencia a métodos, variables o clases que no existen en el contexto. Al proporcionar TROCtx relevantes, Synbciatr pudo reducir considerablemente el número de estas ocurrencias.

#Analizando Fracasos

A pesar de su éxito, hubo algunas instancias en las que Synbciatr no logró reparar casos de prueba como se esperaba. El análisis reveló varias razones comunes para estos fracasos:

1. Clases No Importadas: En algunos casos, el código generado hacía referencia a clases que no estaban importadas, lo que llevó a errores.
2. Cambios Complejos: A veces, los cambios en el método focal eran demasiado intrincados para que los contextos actuales los acomodaran, llevando a alucinaciones obsoletas.
3. Fallos en la Construcción del Contexto: Hubo casos donde el Language Server no pudo recopilar los contextos necesarios debido a problemas con la configuración del repositorio.

#Consideraciones de Eficiencia

El proceso de reunir TROCtx añade algo de tiempo a la operación general de reparar pruebas con Synbciatr en comparación con Naivellm. Sin embargo, el intercambio por este tiempo adicional es una mejor precisión y menos errores en las pruebas generadas. El tiempo promedio que tomó a Synbciatr generar reparaciones se encontró dentro de un rango aceptable para los desarrolladores.

#Conclusión

En conclusión, Synbciatr presenta un método útil para reparar automáticamente casos de prueba obsoletos causados por cambios en el código de producción. Al recopilar y utilizar eficazmente el contexto relevante, ha demostrado superar significativamente a los métodos existentes, produciendo reparaciones de prueba más precisas y exitosas. Los resultados positivos ilustran el potencial de usar un contexto bien construido para mejorar las capacidades de los modelos de lenguaje en tareas de desarrollo de software. Este enfoque no solo alivia las cargas que enfrentan los desarrolladores, sino que también contribuye a la confiabilidad y efectividad general de las prácticas de prueba de software.