Ausgangslage und Forschungsfrage
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.
Methodisches Vorgehen
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.
Die gewonnenen Erkenntnisse
Erstens zeigt sich beim Implementierungsaufwand ein klarer Unterschied: Cypress lässt sich vergleichsweise schnell aufsetzen, weil keine zusätzlichen Browser-Treiber erforderlich sind und viele Konfigurationen out of the box funktionieren. [2] Selenium erfordert dagegen zusätzliche WebDriver je Browser und damit mehr Setup und Pflege. [3]
Zweitens fällt die Umsetzung ähnlicher Tests in Cypress kompakter aus. Für die sechs umgesetzten Tests entstehen in Cypress insgesamt 100 Zeilen Code (LOC), während die Selenium-Variante 141 LOC umfasst. Die Arbeit führt den Unterschied vor allem auf die umfangreichere JavaScript-Syntax und den geringeren Abstraktionsgrad in Selenium zurück.
Drittens unterscheiden sich die Tools deutlich in Ausführung und Laufzeit in der Pipeline: In den gemessenen Läufen benötigt Cypress etwa doppelt so lange wie Selenium. Als wesentliche Ursache wird genannt, dass Cypress stark auf eine browsernahe, visuell orientierte Testausführung und Debugging-Features setzt, während Selenium Tests effizient im Headless-Modus ausführen kann.
Viertens zeigt der Vergleich im SPA-Alltag unterschiedliche Stärken: Cypress ist standardmäßig besser auf typische SPA-Wartebedingungen ausgelegt und reduziert damit manuellen Aufwand beim Synchronisieren von UI-Zuständen. Selenium ist dafür flexibler bei Browserabdeckung und Ausführungsmodi und ist insbesondere dann attraktiv, wenn Tests breit über Browser hinweg und automatisiert in CI/CD laufen sollen. [4]
Was die Ergebnisse bedeuten
Die Ergebnisse sprechen für eine pragmatische Aufgabenteilung statt einer universellen Tool-Empfehlung. Cypress passt gut in die Entwicklungsphase, wenn schnelle Rückmeldungen, interaktives Debugging und eine geringe Einstiegshürde wichtig sind. [2] Selenium spielt seine Stärken aus, wenn eine robuste, wiederholbare und performante Ausführung in CI/CD sowie Cross-Browser-Tests im Fokus stehen. [3]
Gleichzeitig relativiert die Laufzeitmessung einfache Annahmen wie "Cypress ist immer schneller". In Headless-orientierten Pipelines kann die visuelle Ausrichtung von Cypress zum Nachteil werden, während Selenium durch seinen Betriebsmodus Vorteile hat. Entscheidend ist damit weniger ein einzelner Benchmark, sondern die Passung zwischen Tool-Philosophie und Betriebsumgebung.
Zu den Limitationen gehören die begrenzte Anzahl an Tests (sechs Abläufe) und die Abhängigkeit von einer konkreten Anwendung mit bestimmten UI-Patterns. Zudem betrachtet der Vergleich nur zwei Frameworks und lässt z.B. Playwright oder Mischstrategien (E2E + Component Tests) außen vor. Auch bleibt ein Teil der Qualitätssicherung bewusst manuell, wenn Abläufe sehr fragil sind oder hohe Pflegekosten erwarten lassen.
Kernaussagen und Ausblick
Der Vergleich zeigt, dass E2E-Testing in komplexen SPAs vor allem dann Mehrwert liefert, wenn wenige kritische Benutzerabläufe stabil automatisiert werden. Cypress überzeugt mit schneller Einrichtung und einem entwicklerfreundlichen Workflow, während Selenium durch Flexibilität, Browserunterstützung und effiziente Headless-Ausführung in CI/CD punktet. Eine tool-agnostische Strategie, die die Stärken beider Ansätze nutzt, reduziert Reibung in der Entwicklung und erhöht die Zuverlässigkeit im Release-Prozess.
Die Arbeit entstand im Rahmen einer durch die Stack1 GmbH betreuten Bachelorarbeit und nutzt ein praxisnahes Fallbeispiel aus der Webentwicklung.