ReproBreak: A Dataset of Reproducible Web Locator Breaks

Technischer Überblick: ReproBreak

Problemstellung
Automatisierte GUI-Test-Frameworks wie Cypress und Playwright sind stark auf Element-Lokatoren (z. B. IDs, CSS-Selektoren, XPath) angewiesen, um mit Webanwendungen zu interagieren. Ein „Locator-Break" tritt auf, wenn strukturelle Änderungen an der Application Under Test (AUT) – wie das Umbenennen einer Element-ID oder die Umstrukturierung des DOM – dazu führen, dass ein Lokator versagt, selbst wenn die zugrunde liegende Funktionalität korrekt bleibt. Obwohl die Fragilität von Lokatoren ein gut dokumentiertes Problem im GUI-Testing ist, haben bestehende Forschung und Datensätze sich primär auf Selenium konzentriert. Es besteht eine signifikante Lücke in der Literatur bezüglich einer groß angelegten Evaluierung der Lokator-Fragilität speziell für Cypress und Playwright, die im Vergleich zum externen Treiber-Modell von Selenium unterschiedliche interne Mechanismen für das Abfragen und Interagieren mit Elementen nutzen. Folglich existiert kein Datensatz, um Reparaturtechniken und Robustheitsstrategien für diese modernen Frameworks empirisch zu evaluieren oder zu vergleichen.

Methodik
Die Autoren stellten ReproBreak zusammen, einen Datensatz reproduzierbarer Locator-Breaks, durch eine dreistufige automatisierte Pipeline, die auf Open-Source-Repositories angewendet wurde:

1. Datenquelle und Identifikation: Die Studie begann mit dem E2EGit-Datensatz, wobei nach 374 Repositories gefiltert wurde, die Cypress, Playwright oder beides verwenden. Davon wurden 359 Repositories analysiert. Die Autoren identifizierten Testdateien durch Filtern nach spezifischen Erweiterungen (z. B. .spec.ts) und frameworkspezifischen Schlüsselwörtern (z. B. cy.get für Cypress, page.locator für Playwright). Mithilfe von git log und git diff identifizierten sie Commits, die Testdateien modifizierten, und extrahierten Code-Hunks, die Lokator-Änderungen ($L_c$) enthielten.
2. Docker-basierte Umgebungseinrichtung: Um zu validieren, ob eine Lokator-Änderung einen Break darstellte, mussten die Autoren Tests in einer konsistenten Umgebung ausführen. Sie konzentrierten sich auf die Top-10-Projekte mit der höchsten Anzahl an Lokator-Änderungen. Aufgrund des erforderlichen manuellen Aufwands und von Abhängigkeitsproblemen gelang es ihnen, für die Top-4-Projekte reproduzierbare Docker-Umgebungen (enthaltend Dockerfile und Ausführungsskripte) zu erstellen.
3. Validierung von Locator-Breaks: Für jede identifizierte Lokator-Änderung ($L_c$) in den validierten Projekten führten die Autoren eine zweistufige Verifikation durch:
   • Schritt 3a: Ausführung des Tests mit dem neuen Lokator auf der aktualisierten Anwendung. Wenn dieser besteht, ist der neue Lokator gültig.
   • Schritt 3b/c: Ersetzen des neuen Lokators durch den alten Lokator im selben Commit und erneute Ausführung. Wenn der Test fehlschlägt, wird die Änderung als Locator-Break ($L_b$) klassifiziert. Wenn er besteht, wird sie als nicht-brechende Lokator-Änderung ($L_{nb}$) klassifiziert, was darauf hindeutet, dass das Update prophylaktisch war.

Hauptbeiträge

• ReproBreak-Datensatz: Eine strukturierte relationale SQLite-Datenbank mit 449 bestätigten, reproduzierbaren Locator-Breaks über vier große Open-Source-Projekte hinweg. Das Schema verknüpft Lokator-Änderungen mit spezifischen Commits, Repositories und Reproduktionsskripten.
• Automatisierte Reproduktionsskripte: Die Autoren stellen reproduce.py-Skripte bereit, die Forschern ermöglichen, die Docker-Umgebung automatisch einzurichten, den alten Lokator einzufügen und den Break zu bestätigen. Dies geht über statische Momentaufnahmen hinaus hin zu einer dynamischen, ausführbaren Validierung.
• Framework-spezifische Analyse: Der Datensatz zielt spezifisch auf Cypress und Playwright ab und adressiert den Mangel an Ressourcen zur Evaluierung der Fragilität in diesen Frameworks im Vergleich zu Selenium.

Ergebnisse

• Umfang: Die Analyse umfasste 359 Repositories (189 Playwright, 154 Cypress, 16 beides).
• Lokator-Änderungen: Die Pipeline identifizierte insgesamt 9.572 Lokator-Änderungen über die Repositories hinweg.
• Validierung: Nach dem Filtern nach Projekten, für die eine reproduzierbare Docker-Umgebung eingerichtet werden konnte, validierten die Autoren 580 Lokator-Änderungen.
• Identifizierte Breaks: Von den validierten Änderungen wurden 449 als Locator-Breaks bestätigt ($L_b$), während 131 nicht-brechende Änderungen ($L_{nb}$) waren.
• Verteilung: Der Datensatz enthält Daten aus vier Projekten: ghiscoding/angular-slickgrid, nasa/openmct, tryghost/koenig und microsoft/playwright.

Bedeutung und Behauptungen
Das Paper positioniert ReproBreak als grundlegendes Artefakt zur Weiterentwicklung der Forschung in der GUI-Testwartung für moderne Frameworks. Die Autoren behaupten, dass der Datensatz Folgendes ermöglicht:

• Evaluierung von Robustheitstechniken: Forschern die Möglichkeit zu geben, zu testen, ob Selenium-basierte Techniken zur resilienten Lokator-Generierung (z. B. Robula+, Sidereal) auf Cypress und Playwright anwendbar sind.
• Bewertung der Fragilitätsscores: Eine Grundlage zu schaffen, um Fragilitätsscores, die ursprünglich für Selenium entwickelt wurden, an diese neuen Frameworks anzupassen und zu validieren.
• Benchmarking von Reparaturansätzen: Die Bewertung von Lokator-Reparatur-Tools (z. B. Similo, Vista) und die Entwicklung von LLM-basierten Agenten für die automatische Reparatur zu ermöglichen.
• Forschung zu NL-basiertem Testing: Einen groß angelegten Datensatz anzubieten, um die Robustheit von Natural-Language-basierten Testansätzen gegenüber Locator-Breaks zu evaluieren.

Die Autoren betonen, dass die Einbeziehung automatisierter Reproduktionsskripte ein entscheidendes Unterscheidungsmerkmal ist, das Forschern erlaubt, Breaks aktiv zu bestätigen und Reparaturtechniken in einer echten Ausführungsumgebung zu testen, anstatt sich auf statische Analysen zu verlassen. Sie weisen darauf hin, dass der aktuelle Datensatz zwar vier Projekte abdeckt, die Methodik jedoch durch die Definition neuer Lokator-Regex-Muster auf andere Frameworks erweiterbar ist.