Cypress ist ein Testautomatisierungstool für Web-Anwendungen, das sowohl End-to-End-Tests als auch Component-Tests abdeckt. Component-Tests mounten einzelne Komponenten isoliert im echten Browser, ohne die gesamte Anwendung zu starten. Kernvorteile sind visuelles Echtzeit-Feedback während der Testausführung, DOM-Snapshots bei Fehlern und deutlich stabilere Tests gegenüber emulationsbasierten Alternativen wie Jest.
Das Wichtigste in Kürze
- Cypress führt Komponenten-Tests im echten Browser aus, was flaky Tests durch fehlerhafte DOM-Emulation, wie sie etwa bei Jest auftreten, deutlich reduziert.
- Das visuelle Daumenkino-Feature von Cypress zeigt für jeden Teststep einen DOM-Snapshot vor und nach der Aktion, was Debugging-Zeit massiv verkürzt.
- Testparallelisierung, ein kostenpflichtiges Cloud-Feature von Cypress, lässt sich auch selbst implementieren, etwa über GitLab-Pipelines mit mehreren Runnern.
- Die Cypress Testing Library ermöglicht es, Elemente über Labels und Test-IDs statt über fragile DOM-Pfade zu selektieren, was Tests stabiler und benutzerorientierter macht.
Was ist Cypress und wofür wird es genutzt?
Cypress ist ein Testautomatisierungstool für Webanwendungen. Es startete als End-to-End-Werkzeug und positionierte sich anfangs als direkter Gegenspieler zu Selenium, mit dem Versprechen, schneller und stabiler zu sein.
Der Fokus auf Web ist kein Zufall. Es entstehen immer weniger native Clients und immer mehr Webanwendungen, und Cypress ist genau für diese Welt gebaut. Ende 2020 kam ein zweiter Anwendungsbereich dazu: Component Testing.
Der entscheidende technische Unterschied zu vielen Alternativen liegt in der Ausführung. Cypress testet im echten Browser, statt eine Browserumgebung zu emulieren. Tools wie Jest emulieren das Frontend, und diese Emulation wird bei komplexen Oberflächen instabil. In der Praxis äußert sich das in extrem hohen Timeouts, weil gesuchte Elemente nicht erscheinen oder ein Button-Klick ins Leere läuft.
Warum visuelles Feedback das Debugging verändert
Cypress liefert während der Testausführung ein sichtbares Bild der Oberfläche. Du siehst direkt, was das Tool gerade tut, und nicht nur eine Textmeldung über einen nicht gefundenen DOM-Knoten.
Andere Testumgebungen im Angular-Umfeld wie Karma oder Jasmine zeigen ebenfalls die Anwendung während des Tests, sind dabei aber langsam. Cypress kombiniert die Geschwindigkeit eines Tests mit dem visuellen Feedback. Findet ein Test einen Button nicht, siehst du daneben, was Cypress auf der Oberfläche erkennt.
Dehla Sokenou hebt ein Feature besonders hervor: eine Art Daumenkino über die Teststeps. Du fährst mit der Maus über einen einzelnen Schritt und siehst einen DOM-Snapshot vorher und nachher. Gibst du Text in ein Feld ein, ist er im Vorher-Snapshot leer und im Nachher-Snapshot gefüllt. Drückst du einen Löschen-Button, ist das Element davor da und danach weg.
Cypress schafft es, die Schnelligkeit eines Tests zu verbinden mit dem visuellen Feedback. Und das macht es sehr einfach, auf Fehlersuche zu gehen.
Dehla Sokenou
Component Testing dreht die Test-Pyramide wieder richtig herum
Im Frontend werden traditionell sehr viele End-to-End-Tests geschrieben und vergleichsweise wenige Unit- oder Komponententests. Damit steht die Test-Pyramide oft auf dem Kopf. Component Testing wirkt genau diesem Effekt entgegen.
Mit Component Testing prüfst du eine einzelne Komponente losgelöst vom Rest der Anwendung. Die Anwendung muss dafür nicht laufen. Cypress nimmt den vorhandenen Code und mountet die jeweilige Komponente isoliert.
Die Isolation funktioniert über die üblichen Mittel von Component-Test-Frameworks. Du kannst Spies, Mocks oder einen Interceptor nutzen. Der Interceptor fängt etwa API-Calls ab und liefert Standardwerte zurück, sodass die Komponente wirklich als einzelnes Artefakt prüfbar wird.
Die Unterstützung war anfangs auf React und Vue beschränkt, Angular kam später dazu. Auch die Stabilität war zu Beginn ein Problem, selbst für React. Diese Kinderkrankheiten gelten inzwischen als ausgemerzt.
End-to-End und Component Testing im selben Tool
Cypress deckt beide Teststufen ab und trennt sie strukturell sauber. Der praktische Unterschied im Testcode ist gering, aber klar.
Im End-to-End-Test steuerst du mit einem visit eine URL an. Im Component Testing mountest du stattdessen die Komponente direkt. Beide Varianten beginnen mit einem describe für die Beschreibung und nutzen die typische it-Struktur, etwa “it should delete” für einen Testfall, der das Löschen eines Elements per Button-Klick prüft.
Auch die Ablage folgt dieser Trennung. Komponententests liegen als Spec-Dateien direkt neben der Komponente, im Frontend ein üblicher Standard. End-to-End-Tests liegen in einem eigenen Verzeichnis parallel zur Anwendung.
Die End-to-End-Tests in ein separates Repository auszulagern ist technisch möglich, bringt aber einen Nachteil mit sich: Ändert sich die Anwendung, vergisst du leicht, die ausgelagerten Tests anzupassen. Same Repository, andere Stelle, ist deshalb meist die bessere Wahl.
Test-Driven Development im Frontend wird greifbar
Cypress eignet sich für test-driven Development im Frontend, weil die Toolunterstützung das Schreiben von Tests vor der Implementierung erleichtert. Genau diese Unterstützung ist die Voraussetzung dafür, dass TDD im Alltag funktioniert.
Der Ablauf ist konkret. Du baust eine leere Komponente, schreibst einen Test, und siehst, dass die erwarteten Elemente fehlen. Dann ergänzt du die Elemente. Im nächsten Schritt prüfst du etwa, ob ein Input-Feld ein Pflichtfeld ist, der Test schlägt fehl, und du fügst die Eigenschaft in der Komponente hinzu.
Der Cypress Runner läuft dabei neben der IDE und startet bei jeder Änderung am Frontend den Test automatisch neu. Du musst nicht erst auf einen Play-Button drücken, sondern fährst den Runner einmal hoch und siehst laufend, wie weit du bist.
Stabiler als die Vorgänger, auch in der Pipeline
Der größte praktische Gewinn nach der Umstellung von Jest auf Cypress sind deutlich weniger flaky Tests. Flaky Tests sind die Blinker, die mal durchlaufen und mal umfallen, ohne dass sich am Code etwas geändert hat.
Bei der Migration wurden gezielt zuerst die Problemfälle angegangen: die Langläufer mit hohen Timeouts und die instabilen Tests. Das Ergebnis: Cypress läuft trotz echtem Browser schnell genug und produziert spürbar weniger Blinker. Drei regelmäßig umfallende Tests können sonst dazu führen, dass du beim Deployen zwanzig Mal auf den Knopf drückst, bis es durchläuft.
Auch die Fehlersuche in der Pipeline profitiert. Im Fehlerfall legt Cypress einen DOM-Snapshot als Screenshot ab. So wurde sichtbar, dass manche Tests fehlschlugen, weil noch Toasts über anderen Elementen lagen und diese verdeckten. Ein Bild zeigt das sofort, eine reine Textmeldung nicht.
Wie viele Tests laufen, und wie schnell?
Die Geschwindigkeit der Testausführung ist hoch, obwohl im echten Browser getestet wird. Das einmalige Hochfahren des Runners dauert etwas, die eigentliche Ausführung läuft danach sehr schnell.
Im genannten Projekt liegt das Verhältnis bei rund 500 zu 600 Tests im Vergleich zwischen verbliebenen Jest-Tests und Cypress-Tests, wobei es inzwischen mehr Cypress-Tests gibt. Diese Frontend-Tests laufen unter zehn Minuten, etwa so lange wie die Backend-Tests.
Möglich macht das die Parallelisierung. Die Frontend-Testsuite wird in kleinere Häppchen aufgeteilt, jedes Häppchen läuft auf einem eigenen Runner. Frontend- und Backend-Tests sind dadurch ungefähr gleichzeitig fertig, sodass das Paketieren auf keine Seite warten muss. Bei Bedarf lassen sich weitere Runner ergänzen.
Open Source mit kommerziellem Kern, aber selten gebraucht
Cypress ist ein Open-Source-Projekt mit einer kommerziellen Firma dahinter. Die Open-Source-Variante lässt sich praktisch ohne Einschränkungen nutzen.
Einige Funktionen bleiben der kommerziellen Variante vorbehalten, etwa die Testparallelisierung über die Cloud sowie ein Management-Dashboard und Flaky-Test-Management. Die Parallelisierung lässt sich aber selbst abbilden, im genannten Fall über eine GitLab-Pipeline, die die Testsuite aufteilt und auf mehrere Runner verteilt. Dafür braucht es die kommerzielle Cloud nicht.
Eine kleine Umfrage im Publikum bestätigte das Muster: Viele setzen Cypress ein, niemand meldete sich für die kommerzielle Variante. Für viele Teams ist die Open-Source-Version ein guter Einstieg, und die Zusatzfeatures lassen sich bei Bedarf nachbuchen oder selbst bauen.
Wo Cypress an Grenzen stößt
Cypress ist ein Werkzeug für Webanwendungen, und genau dort liegen auch die Grenzen. Hast du neben der Webanwendung native Clients, die du gemeinsam end-to-end testen willst, ist Cypress das falsche Tool.
Auch beim Multitabbing wird es eng. Eine Anwendung mit mehreren Tabs lässt sich nur mit Workarounds abdecken, und in solchen Fällen passt Cypress oft nicht. Für ein Backend in Java bleibt ohnehin ein anderes Werkzeug wie JUnit die richtige Wahl. Tools sollten passend eingesetzt werden, nicht erzwungen.
Dazu kommt das Tempo der Webentwicklung. Mit Playwright gibt es eine ernstzunehmende Alternative, und das Feld verändert sich schneller, als man alles sichten kann. Ob Cypress morgen noch das Tool der Wahl ist, lässt sich nicht garantieren.
Tipps für den Einstieg
Wer mit Cypress startet, sollte zwei Dinge beachten: ein wenig Konfiguration und die passende Hilfsbibliothek. Manche Dinge funktionieren nicht direkt out of the box, deshalb lohnt sich ein Blick in die Konfigurationsmöglichkeiten.
Die klarere Empfehlung betrifft die Testing Library für Cypress. Mit ihr schreibst du Tests aus Benutzersicht statt über DOM-Pfade. Du suchst einen Button mit bestimmter Test-ID oder mit einem bestimmten Label, oder ein Eingabefeld mit einem bestimmten Label.
Diese Schreibweise ist intuitiver und die resultierenden Tests sind deutlich stabiler. Die Migration zwischen Versionen ist einfach, solange du sie laufend mitmachst. Was du vermeiden solltest: Updates lange liegen lassen und Migrationsschritte überspringen.
Häufig gestellte Fragen
Warum gelten Frontend-Tests mit emulierter Browserumgebung als instabil?
Die Emulation des Frontends wird bei komplexen Oberflächen unzuverlässig: Gesuchte Elemente erscheinen nicht, ein Button-Klick läuft ins Leere, und kompensiert wird das mit extrem hohen Timeouts. Cypress führt die Tests stattdessen im echten Browser aus. Bei der beschriebenen Migration von Jest wurden zuerst genau die Problemfälle angegangen, die Langläufer und die instabilen Tests, und die Zahl der flaky Tests sank deutlich.
Warum steht die Test-Pyramide im Frontend oft auf dem Kopf?
Weil traditionell sehr viele End-to-End-Tests und vergleichsweise wenige Unit- oder Komponententests geschrieben werden. Component Testing wirkt dem entgegen: Eine einzelne Komponente wird isoliert gemountet, die Anwendung muss dafür nicht laufen. Für die Isolation dienen die üblichen Mittel, also Spies, Mocks oder ein Interceptor, der etwa API-Calls abfängt und Standardwerte zurückgibt.
Lässt sich Test-Driven Development im Frontend praktisch umsetzen?
Ja, wenn die Toolunterstützung das Schreiben von Tests vor der Implementierung erleichtert. Der Ablauf ist konkret: leere Komponente bauen, Test schreiben, die fehlenden Elemente sehen, Elemente ergänzen. Danach prüft man etwa, ob ein Eingabefeld ein Pflichtfeld ist, sieht den Test fehlschlagen und zieht die Eigenschaft nach. Der Runner läuft neben der IDE und startet bei jeder Änderung selbst neu.
Wie findet man heraus, warum ein Test nur in der Pipeline umfällt?
Über Bilder statt Textmeldungen. Cypress legt im Fehlerfall einen DOM-Snapshot als Screenshot ab. So wurde in einem Projekt sichtbar, dass Tests scheiterten, weil noch Toasts über anderen Elementen lagen und diese verdeckten. Eine reine Meldung über einen nicht gefundenen DOM-Knoten hätte diese Ursache nicht offengelegt.
Bremst das Testen im echten Browser die Continuous-Integration-Pipeline aus?
Nein. Zeit kostet vor allem das einmalige Hochfahren des Runners, die eigentliche Ausführung läuft schnell. Im beschriebenen Projekt lagen rund 500 verbliebene Jest-Tests und rund 600 Cypress-Tests nebeneinander, und die Frontend-Tests blieben unter zehn Minuten, etwa auf dem Niveau der Backend-Tests. Möglich machte das die Aufteilung der Suite auf mehrere Runner.
Braucht man für parallele Testausführung die kostenpflichtige Variante?
Nein. Der kommerziellen Variante waren 2023 die Parallelisierung über die Cloud, ein Management-Dashboard und Flaky-Test-Management vorbehalten. Die Parallelisierung wurde im beschriebenen Fall selbst gebaut: Eine GitLab-Pipeline teilte die Testsuite in kleinere Häppchen und verteilte sie auf mehrere Runner. Eine Umfrage im Publikum zeigte, dass viele Cypress einsetzten, aber niemand die kommerzielle Version.
Kann man mit Cypress auch native Clients oder ein Java-Backend testen?
Nein. Das Werkzeug ist auf Webanwendungen ausgelegt. Wer native Clients gemeinsam mit der Webanwendung end-to-end prüfen will, greift besser zu einem anderen Tool, und für ein Java-Backend bleibt JUnit passend. Auch Anwendungen mit mehreren Tabs lassen sich nur über Workarounds abdecken. Mit Playwright stand 2023 zudem eine ernstzunehmende Alternative im Feld.
Warum sind Tests fragil, die Elemente über DOM-Pfade suchen?
DOM-Pfade brechen, sobald sich die Struktur der Oberfläche ändert. Die Cypress Testing Library selektiert stattdessen aus Benutzersicht: einen Button über eine Test-ID oder ein Label, ein Eingabefeld über sein Label. Diese Schreibweise liest sich intuitiver und liefert stabilere Tests. Ein zweiter Hinweis für den Einstieg: Updates nicht liegen lassen und keine Migrationsschritte überspringen.
