ReproBreak: A Dataset of Reproducible Web Locator Breaks

Résumé Technique : ReproBreak

Énoncé du Problème
Les frameworks de tests automatisés d'interfaces graphiques (GUI) comme Cypress et Playwright reposent fortement sur des sélecteurs d'éléments (par exemple, des identifiants, des sélecteurs CSS, XPath) pour interagir avec les applications web. Une « rupture de sélecteur » se produit lorsque des modifications structurelles de l'Application Sous Test (AUT) — telles que le renommage d'un identifiant d'élément ou la restructuration du DOM — entraînent l'échec d'un sélecteur, même si la fonctionnalité sous-jacente reste correcte. Bien que la fragilité des sélecteurs soit un défi bien documenté dans les tests d'interfaces graphiques, les recherches et jeux de données existants se sont principalement concentrés sur Selenium. Il existe un écart significatif dans la littérature concernant l'évaluation à grande échelle de la fragilité des sélecteurs spécifiquement pour Cypress et Playwright, qui utilisent des mécanismes internes différents pour interroger et interagir avec les éléments par rapport au modèle de pilote externe de Selenium. Par conséquent, aucun jeu de données n'existe pour évaluer ou comparer empiriquement les techniques de réparation de sélecteurs et les stratégies de robustesse pour ces frameworks modernes.

Méthodologie
Les auteurs ont construit ReproBreak, un jeu de données de ruptures de sélecteurs reproductibles, grâce à un pipeline automatisé en trois étapes appliqué à des dépôts open source :

1. Source de Données et Identification : L'étude a débuté avec le jeu de données E2EGit, filtré pour retenir 374 dépôts utilisant Cypress, Playwright ou les deux. Parmi ceux-ci, 359 dépôts ont été analysés. Les auteurs ont identifié les fichiers de test en filtrant des extensions spécifiques (par exemple, .spec.ts) et des mots-clés propres aux frameworks (par exemple, cy.get pour Cypress, page.locator pour Playwright). En utilisant git log et git diff, ils ont identifié les commits modifiant les fichiers de test et extrait les fragments de code contenant des modifications de sélecteurs ($L_c$).
2. Configuration de l'Environnement Basée sur Docker : Pour valider si une modification de sélecteur constituait une rupture, les auteurs devaient exécuter les tests dans un environnement cohérent. Ils se sont concentrés sur les 10 projets présentant le plus grand nombre de modifications de sélecteurs. En raison des exigences en matière d'effort manuel et des problèmes de dépendances, ils ont réussi à créer des environnements Docker reproductibles (contenant un Dockerfile et des scripts d'exécution) pour les 4 premiers projets.
3. Validation de la Rupture de Sélecteur : Pour chaque modification de sélecteur identifiée ($L_c$) dans les projets validés, les auteurs ont effectué une vérification en deux étapes :
   • Étape 3a : Exécuter le test avec le nouveau sélecteur sur l'application mise à jour. S'il réussit, le nouveau sélecteur est valide.
   • Étape 3b/c : Remplacer le nouveau sélecteur par l'ancien sélecteur dans le même commit et réexécuter. Si le test échoue, la modification est classée comme une rupture de sélecteur ($L_b$). S'il réussit, elle est classée comme une modification de sélecteur non rompante ($L_{nb}$), indiquant que la mise à jour était prophylactique.

Contributions Clés

• Jeu de Données ReproBreak : Une base de données relationnelle structurée SQLite contenant 449 ruptures de sélecteurs confirmées et reproductibles à travers quatre grands projets open source. Le schéma lie les modifications de sélecteurs à des commits spécifiques, des dépôts et des scripts de reproduction.
• Scripts de Reproduction Automatisés : Les auteurs fournissent des scripts reproduce.py permettant aux chercheurs de configurer automatiquement l'environnement Docker, d'injecter l'ancien sélecteur et de confirmer la rupture. Cela va au-delà des instantanés statiques pour une validation dynamique et exécutable.
• Analyse Spécifique aux Frameworks : Le jeu de données cible spécifiquement Cypress et Playwright, comblant le manque de ressources pour évaluer la fragilité dans ces frameworks par rapport à Selenium.

Résultats

• Portée : L'analyse a porté sur 359 dépôts (189 Playwright, 154 Cypress, 16 les deux).
• Modifications de Sélecteurs : Le pipeline a identifié un total de 9 572 modifications de sélecteurs à travers les dépôts.
• Validation : Après filtrage pour les projets où un environnement Docker reproductible pouvait être établi, les auteurs ont validé 580 modifications de sélecteurs.
• Ruptures Identifiées : Parmi les modifications validées, 449 ont été confirmées comme des ruptures de sélecteurs ($L_b$), tandis que 131 étaient des modifications non rompantes ($L_{nb}$).
• Distribution : Le jeu de données inclut des données provenant de quatre projets : ghiscoding/angular-slickgrid, nasa/openmct, tryghost/koenig et microsoft/playwright.

Signification et Revendications
L'article positionne ReproBreak comme un artefact fondamental pour faire progresser la recherche sur la maintenance des tests d'interfaces graphiques pour les frameworks modernes. Les auteurs affirment que le jeu de données permet :

• Évaluation des Techniques de Robustesse : Permettre aux chercheurs de tester si les techniques de génération de sélecteurs résilients basées sur Selenium (par exemple, Robula+, Sidereal) sont applicables à Cypress et Playwright.
• Évaluation du Score de Fragilité : Fournir une base pour adapter et valider les scores de fragilité initialement conçus pour Selenium à ces nouveaux frameworks.
• Étalonnage des Approches de Réparation : Permettre l'évaluation des outils de réparation de sélecteurs (par exemple, Similo, Vista) et le développement d'agents basés sur les LLM pour la réparation automatisée.
• Recherche sur les Tests Basés sur le Langage Naturel : Offrir un jeu de données à grande échelle pour évaluer la robustesse des approches de test basées sur le langage naturel face aux ruptures de sélecteurs.

Les auteurs soulignent que l'inclusion de scripts de reproduction automatisés est un différentiateur critique, permettant aux chercheurs de confirmer activement les ruptures et de tester les techniques de réparation dans un environnement d'exécution réel plutôt que de s'appuyer sur une analyse statique. Ils notent que, bien que le jeu de données actuel couvre quatre projets, la méthodologie est extensible à d'autres frameworks en définissant de nouveaux motifs regex pour les sélecteurs.