End-to-End-Testframeworks für komplexe Single-Page-Webanwendungen - Vergleich und Integration am Beispiel des Formforge-Editors

Single-Page-Webanwendungen (SPA) wie moderne React-Frontends reagieren stark auf Benutzerinteraktionen, asynchrone Requests und dynamische UI-Zustände. Genau diese Kombination macht sie im Alltag fehleranfällig: Eine kleine Änderung an Routing, State-Management oder UI-Komponenten kann Abläufe brechen, die erst im Zusammenspiel mehrerer Screens sichtbar werden.

End-to-End-Tests (E2E) setzen hier an, weil sie die Anwendung aus Nutzersicht prüfen: im Browser, über echte Klicks, Eingaben und Navigation. Gleichzeitig ist E2E-Testing bei komplexen SPAs teuer, weil Testdaten, Wartebedingungen und Selektoren gepflegt werden müssen und weil nicht jeder Ablauf sinnvoll automatisierbar ist.

Diese Pflegekosten entstehen nicht nur durch Code, sondern auch durch typische E2E-Probleme wie instabile Synchronisation (Flakiness), fragile Selektoren und schwer reproduzierbare Umgebungszustände. [1]

Die zentrale Forschungsfrage lautet: Wie unterscheiden sich Cypress und Selenium bei Implementierungsaufwand, Wartbarkeit und Laufzeit von End-to-End-Tests für eine komplexe React-basierte SPA, und welches Tool eignet sich für Entwicklung und CI/CD besser?

Die Arbeit grenzt sich bewusst von Unit- und Component-Tests ab und fokussiert auf E2E-Tests als Absicherung zentraler Benutzerabläufe. Zudem steht nicht eine abstrakte Tool-Bewertung im Vordergrund, sondern ein praxisnaher Vergleich anhand eines realen Editors mit vielen UI-Zuständen.

Als Fallbeispiel dient ein React-basierter Online-Formular-Editor mit typischen SPA-Eigenschaften: dynamische Oberflächen, komplexe Interaktionen und asynchrone Updates. Für diese Anwendung werden zentrale Benutzerabläufe als automatisierte E2E-Tests modelliert, um die Aussagekraft der Tools im realistischen Kontext zu prüfen.

Im Vergleich stehen die Frameworks Cypress und Selenium. Bewertet werden (1) Einrichtung und Integration, (2) Umsetzung typischer Testschritte, (3) Umgang mit SPA-Synchronisation und (4) Betrieb in einer CI/CD-Pipeline. Dafür werden sechs Tests implementiert, die unter anderem Login sowie das Erstellen von Formularen simulieren.

Neben der qualitativen Betrachtung (Debugging, Entwickler-Workflow, Selektoren) werden auch zwei quantitative Indikatoren erhoben: die Anzahl der geschriebenen Testzeilen (LOC, ohne Leer- und Kommentarzeilen) sowie die Ausführungszeit. Die Zeitmessung erfolgt bei Cypress über die Konsolenausgabe im Headless-Betrieb, bei Selenium über explizite Start-/Endzeitmessung im Testcode.