ReproBreak: A Dataset of Reproducible Web Locator Breaks

Resumen Técnico: ReproBreak

Enunciado del Problema
Los marcos de trabajo de pruebas automatizadas de GUI como Cypress y Playwright dependen en gran medida de localizadores de elementos (por ejemplo, IDs, selectores CSS, XPath) para interactuar con aplicaciones web. Un "fallo de localizador" ocurre cuando cambios estructurales en la Aplicación Bajo Prueba (AUT), como la renominación de un ID de elemento o la reestructuración del DOM, provocan que un localizador falle, incluso si la funcionalidad subyacente permanece correcta. Aunque la fragilidad de los localizadores es un desafío bien documentado en las pruebas de GUI, la investigación y los conjuntos de datos existentes se han centrado principalmente en Selenium. Existe una brecha significativa en la literatura respecto a la evaluación a gran escala de la fragilidad de los localizadores específicamente para Cypress y Playwright, los cuales utilizan mecanismos internos diferentes para consultar e interactuar con elementos en comparación con el modelo de controlador externo de Selenium. En consecuencia, no existe un conjunto de datos para evaluar empíricamente o comparar técnicas de reparación de localizadores y estrategias de robustez para estos marcos de trabajo modernos.

Metodología
Los autores construyeron ReproBreak, un conjunto de datos de fallos de localizadores reproducibles, mediante una tubería automatizada de tres etapas aplicada a repositorios de código abierto:

1. Fuente de Datos e Identificación: El estudio comenzó con el conjunto de datos E2EGit, filtrando 374 repositorios que utilizan Cypress, Playwright o ambos. De estos, se analizaron 359 repositorios. Los autores identificaron archivos de prueba filtrando extensiones específicas (por ejemplo, .spec.ts) y palabras clave específicas del marco (por ejemplo, cy.get para Cypress, page.locator para Playwright). Utilizando git log y git diff, identificaron commits que modificaron archivos de prueba y extrajeron fragmentos de código que contenían cambios en localizadores ($L_c$).
2. Configuración del Entorno Basado en Docker: Para validar si un cambio en un localizador constituía un fallo, los autores necesitaban ejecutar pruebas en un entorno consistente. Se centraron en los 10 proyectos principales con el mayor número de cambios en localizadores. Debido a los requisitos de esfuerzo manual y problemas de dependencias, crearon con éxito entornos Docker reproducibles (que contenían Dockerfile y scripts de ejecución) para los 4 proyectos principales.
3. Validación de Fallos de Localizador: Para cada cambio de localizador identificado ($L_c$) en los proyectos validados, los autores realizaron una verificación en dos pasos:
   • Paso 3a: Ejecutar la prueba con el nuevo localizador en la aplicación actualizada. Si pasa, el nuevo localizador es válido.
   • Paso 3b/c: Reemplazar el nuevo localizador con el antiguo localizador en el mismo commit y volver a ejecutar. Si la prueba falla, el cambio se clasifica como un fallo de localizador ($L_b$). Si pasa, se clasifica como un cambio de localizador no fallido ($L_{nb}$), lo que indica que la actualización fue profiláctica.

Contribuciones Clave

• Conjunto de Datos ReproBreak: Una base de datos relacional estructurada SQLite que contiene 449 fallos de localizadores confirmados y reproducibles a través de cuatro proyectos principales de código abierto. El esquema vincula los cambios de localizadores con commits específicos, repositorios y scripts de reproducción.
• Scripts de Reproducción Automatizada: Los autores proporcionan scripts reproduce.py que permiten a los investigadores configurar automáticamente el entorno Docker, inyectar el localizador antiguo y confirmar el fallo. Esto va más allá de las instantáneas estáticas hacia una validación dinámica y ejecutable.
• Análisis Específico del Marco de Trabajo: El conjunto de datos se dirige específicamente a Cypress y Playwright, abordando la falta de recursos para evaluar la fragilidad en estos marcos de trabajo en comparación con Selenium.

Resultados

• Alcance: El análisis cubrió 359 repositorios (189 Playwright, 154 Cypress, 16 ambos).
• Cambios de Localizador: La tubería identificó un total de 9.572 cambios de localizadores en los repositorios.
• Validación: Después de filtrar proyectos donde se pudo establecer un entorno Docker reproducible, los autores validaron 580 cambios de localizadores.
• Fallos Identificados: De los cambios validados, 449 fueron confirmados como fallos de localizadores ($L_b$), mientras que 131 fueron cambios no fallidos ($L_{nb}$).
• Distribución: El conjunto de datos incluye datos de cuatro proyectos: ghiscoding/angular-slickgrid, nasa/openmct, tryghost/koenig y microsoft/playwright.

Significancia y Afirmaciones
El artículo posiciona a ReproBreak como un artefacto fundamental para avanzar en la investigación sobre el mantenimiento de pruebas de GUI para marcos de trabajo modernos. Los autores afirman que el conjunto de datos permite:

• Evaluación de Técnicas de Robustez: Permitir a los investigadores probar si las técnicas de generación de localizadores resilientes basadas en Selenium (por ejemplo, Robula+, Sidereal) son aplicables a Cypress y Playwright.
• Evaluación de Puntuaciones de Fragilidad: Proporcionar una base para adaptar y validar puntuaciones de fragilidad diseñadas originalmente para Selenium a estos nuevos marcos de trabajo.
• Pruebas de Enfoques de Reparación: Habilitar la evaluación de herramientas de reparación de localizadores (por ejemplo, Similo, Vista) y el desarrollo de agentes basados en LLM para la reparación automatizada.
• Investigación de Pruebas Basadas en NL: Ofrecer un conjunto de datos a gran escala para evaluar la robustez de los enfoques de pruebas basados en Lenguaje Natural frente a fallos de localizadores.

Los autores enfatizan que la inclusión de scripts de reproducción automatizada es un diferenciador crítico, permitiendo a los investigadores confirmar activamente fallos y probar técnicas de reparación en un entorno de ejecución real en lugar de depender del análisis estático. Señalan que, aunque el conjunto de datos actual cubre cuatro proyectos, la metodología es extensible a otros marcos de trabajo definiendo nuevos patrones de expresiones regulares para localizadores.