Eine Seite kann Status 200 liefern und trotzdem kaputt sein. Bei uns ist genau das passiert: Ein externer Dienst lud nicht, statt der Seite stand nur ein Fehlertext da. Der Server meldete alles in Ordnung. Solche Fehler findet kein Unit Test und keine statische Analyse. Die findet nur ein Test, der die Seite so benutzt wie ein Mensch. Genau dafür gibt es End to End Tests. Sie prüfen eine Anwendung von Anfang bis Ende im echten Browser, mit Datenbank, Server und allen Diensten, die dazugehören.
NCA Cypress Workshop mit Roland Golla: Roland ist Cypress Ambassador, zeigt in über 70 Live Coding Tutorials auf dem NCA YouTube Kanal, wie Cypress in echten Projekten läuft, und pflegt mit NCA TESTIFY ein eigenes Plugin für Basistests mit einer Zeile im CI/CD Setup. Zum Cypress Workshop
Warum End to End Tests heute Pflicht sind
Egal ob ihr per Vibe Coding, mit einem KI Agenten oder ganz von Hand entwickelt: Am Ende muss die Anwendung im Browser laufen. Und genau dort gehen Dinge kaputt, die im Code niemand sieht:
- Infrastruktur: Die Datenbank ist nicht verbunden, ein Cache lässt sich nicht leeren, ein Redirect zeigt ins Leere.
- Externe Dienste: Ein Embed, eine Schnittstelle oder ein Tracking Skript fällt aus oder ändert sich.
- Nebenwirkungen: Eine Änderung an einem JavaScript legt ganz woanders ein Formular lahm.
- Templates: Eine einzelne Seite nutzt ein anderes Template und bricht, während der Rest läuft.
Mit KI wird das Problem größer. Agenten schreiben Code in Sekunden und behaupten gern, sie hätten alle Checks ausgeführt. Oft stimmt das nicht. Und Kleinigkeiten wie das Absenden eines Formulars mit Enter schießen sie gern nebenbei ab. Kein Mensch klickt nach jedem Deployment jeden Weg durch die Seite. Ein E2E Test tut das jedes Mal, in wenigen Sekunden. Warum E2E Tests mit Agenten zum wichtigsten Gate werden, zeigt auch die Testpyramide für KI Agents.
Was gute End to End Tests abdecken
Gute Tests prüfen mehr als den Statuscode. Sie schauen in die geladene Seite hinein und gehen die Wege, mit denen ihr Geld verdient. In der Praxis haben sich vier Ebenen bewährt:
| Ebene | Was geprüft wird | Typisches Beispiel |
|---|---|---|
| Basis Tests | Links, Bilder, Inhalt, Ladezeiten auf jeder Seite | Alle internen Links liefern 200 und die Seiten sind nicht leer |
| Kritische Abläufe | Wege, an denen Umsatz oder Anfragen hängen | Kontaktformular, Login, Warenkorb und Checkout bis zum Absenden |
| Pipeline | Jedes Deployment auf einer Staging Umgebung | Tests laufen nach dem Build, bevor etwas live geht |
| Monitoring | Live Umgebung in festen Abständen, nur lesend | Nächtlicher Lauf erkennt geänderte Schnittstellen und ausgefallene Dienste |
Beim Monitoring gilt eine klare Regel: Gegen Live laufen nur Tests, die nichts Echtes auslösen. Eine Buchung oder Bestellung gehört nicht in den nächtlichen Lauf. Mit Tags trennt ihr diese Gruppen sauber, zum Beispiel über Cypress Grep. Für Staging mit sensiblen Daten arbeitet ihr mit Faker und Dummy Daten. Wie das in der Pipeline aussieht, zeigt Staging ohne Produktionsdaten.
E2E Tests ersetzen dabei keine anderen Prüfungen. Statische Analyse wie PHPStan oder ESLint läuft vorher und findet Fehler im Code absolut zuverlässig, ohne dass eine KI um ihre Meinung gefragt wird. Unit Tests prüfen die Logik. Welche Prüfungen in welcher Reihenfolge laufen, fasst Quality Gates in der Pipeline zusammen.
Was NCA beim Testing anders macht
Roland Golla macht seit über 20 Jahren Testing und Refactoring und ist offizieller Cypress Ambassador. Aus dieser Erfahrung ist ein Setup entstanden, das sich in jedes Projekt einbauen lässt:
- Basis Tests mit einer Zeile: Unser Open Source Plugin NCA TESTIFY bringt fertige Checks für Links, Bilder, SEO und Barrierefreiheit mit. Eine Zeile im CI/CD Setup reicht.
- Custom Tests für euer Geschäft: Darauf bauen wir Tests für die Abläufe, an denen bei euch Anfragen und Umsatz hängen.
- Tests in eigenen Repositories: Die Tests leben getrennt von eurem Projekt und laufen in unserer Infrastruktur. Mehr dazu im nächsten Abschnitt.
- Nachweisbare Ergebnisse: Jeder Lauf landet in Cypress Cloud. Ihr seht, was getestet wurde und warum etwas fehlschlug.
- Offen und nachvollziehbar: Unser eigenes Setup ist Open Source. Ihr könnt jederzeit nachsehen, wie wir arbeiten.
Tests getrennt vom Projekt und ohne Zugang zu euren Servern
Stellt euch einen Shop vor. Ein Tester schreibt neue Tests und will sie vier, fünf, sechs Mal am Tag live bringen. Liegen die Tests im Shop Repository, läuft jedes Mal ein komplettes Shop Deployment. Dazu kommen Reviews im Hauptprojekt, eine Node Version für die Tests und Dependencies, die der Shop gar nicht braucht. Das bremst alle.
Deshalb trennen wir das. Eure Pipeline startet die Tests nach dem Deployment per Schnittstelle in unserer Infrastruktur, wartet auf das Ergebnis und bekommt den Status zurück. In GitLab geht das mit einer Downstream Pipeline:
e2e_tests:
stage: e2e
trigger:
project: nca/cypress-custom-tests
strategy: dependMit strategy depend übernimmt euer Job den Status der Tests. Werden die Tests rot, wird auch eure Pipeline rot. Das bringt euch drei Vorteile:
| Vorteil | Was das für euch bedeutet |
|---|---|
| Kein Zugriff auf Production | Wer bei uns Tests schreibt, braucht weder euren Quellcode noch SSH Keys für eure Server |
| Neue Tests ohne Deployment | Tests gehen mehrmals am Tag live, ohne dass eure Anwendung neu ausgerollt wird |
| Saubere Dependencies | Pakete und Node Version der Tests stören euer Projekt nicht, Renovate hält das Test Repository selbst aktuell |
Basis Tests lassen sich so sogar für mehrere Projekte aus einem Repository betreiben. Wie wir Pipelines dafür aufsetzen, steht beim GitLab CI/CD Pipeline Setup.
Ein Beispiel aus unserem eigenen Projekt
Wie das konkret aussieht, zeigt Roland im aktuellen Video an nevercodealone.de. Drei Tests stehen dort im Mittelpunkt:
- Linkcheck: Der Test findet auf der Startseite 89 interne Links, lädt eine Auswahl von 20 Seiten komplett und prüft Inhalt, Links und jedes Bild. Diesen Test gibt es, seit uns Status 200 einmal getäuscht hat.
- Kontaktformular: Unser mehrstufiges Formular wird bei jedem Lauf in rund drei Sekunden durchgeklickt, über alle Themenpfade bis zum Absenden. Die Anfrage kommt per Mail, in der Datenbank und als Telegram Nachricht an.
- Glossar und Sitemap: Eigene Tests prüfen, ob alle Glossarseiten und alle Seiten aus der Sitemap laden.
Einmal wurde der Formular Test rot. Der Screenshot im Lauf zeigte sofort den Grund: Nach mehreren Deployments an einem Tag hatte unser Rate Limit gegriffen. Der Fix dauerte Minuten. Ohne Test wäre das nie aufgefallen, und ohne Screenshot hätte die Suche lange gedauert.
Cypress Cloud macht Fehler nachweisbar
Ein roter Test ist nur so gut wie die Information dahinter. Mit Test Replay öffnet ihr jeden Lauf in Cypress Cloud und springt durch die Zeit. Jeder Request ist da, mit Status und Ladezeit, dazu Konsole und DOM. Laut der Cypress Doku zu Test Replay braucht das Cypress 13 oder neuer und einen Chromium Browser. Passwort und Zahlungsfelder maskiert Cypress standardmäßig schon vor dem Upload.
Das hilft auch im Gespräch mit Kunden. Meldet jemand eine kaputte Seite und es lag an einem externen Dienst, dann steht das im Replay. Die Oberfläche versteht auch jemand aus dem Projektmanagement. Eingerichtet ist Cypress Cloud mit einer Project ID und einem Record Key, die Schritte beschreibt die Setup Anleitung von Cypress Cloud. Für uns ist das ein klarer Vorteil von Cypress, unsere Einordnung steht im Vergleich Cypress oder Playwright.
So startet ihr mit End to End Tests
- Kostenloses Vorgespräch: Wir schauen auf Projekt, Stack und Pipeline und klären, welche Abläufe geschäftskritisch sind.
- Basis Tests aktivieren: NCA TESTIFY läuft nach dem ersten Setup bei jedem Deployment mit.
- Kritische Abläufe absichern: Wir schreiben die Custom Tests für eure wichtigsten Wege.
- Pipeline und Cloud verbinden: Tests laufen getrennt von eurem Projekt, Ergebnisse landen in Cypress Cloud.
Den Aufwand schätzen wir vorab, abgerechnet wird transparent nach Minuten. Wer Tests im Team selbst schreiben will, lernt das im Cypress Workshop mit Roland Golla. Alle Begriffe rund um Cypress erklärt das NCA Cypress Glossar, das Plugin liegt auf GitHub bei ncatestify.
Häufige Fragen zu End to End Tests
Was sind End to End Tests 2026?
Automatisierte Tests, die eine Anwendung im echten Browser benutzen wie ein Mensch. Sie klicken durch Seiten, füllen Formulare aus und prüfen das Ergebnis. Dabei läuft alles mit, was dazugehört: Server, Datenbank und externe Dienste. So zeigen sie, ob die Anwendung als Ganzes funktioniert.
Brauche ich 2026 noch E2E Tests, wenn ich Unit Tests habe?
Ja. Unit Tests prüfen einzelne Funktionen isoliert. Fehler im Zusammenspiel von Frontend, Backend, Infrastruktur und externen Diensten finden sie nicht. Genau dort entstehen aber viele Ausfälle. Beide Testarten ergänzen sich, dazu kommt statische Analyse als erster Filter.
Warum werden E2E Tests 2026 mit KI wichtiger?
KI Agenten schreiben Code schnell, prüfen aber nicht zuverlässig, ob die Anwendung für Nutzer funktioniert. Oft behaupten sie, Checks ausgeführt zu haben, ohne es getan zu haben. E2E Tests in der Pipeline prüfen das unabhängig bei jedem Deployment und stoppen kaputte Änderungen, bevor sie live gehen.
Muss NCA für die Tests Zugriff auf unsere Server haben?
Nein. Die Tests liegen in eigenen Repositories und laufen in unserer Infrastruktur gegen eure Staging oder Live Umgebung. Eure Pipeline startet sie per Schnittstelle und bekommt das Ergebnis zurück. Quellcode und SSH Keys bleiben bei euch.
Reicht ein Check auf Status 200?
Nein. Eine Seite kann Status 200 liefern und trotzdem nur eine Fehlermeldung zeigen, etwa wenn ein externer Dienst ausfällt. Gute Tests prüfen deshalb auch Inhalt, Links und Bilder der geladenen Seite. Für Formulare und Checkout braucht es eigene Tests bis zum Absenden.
End to End Tests, auf die ihr euch jeden Morgen verlassen könnt
Wir richten Basis Tests, Custom Tests für eure kritischen Abläufe und Cypress Cloud ein, getrennt von eurem Projekt und ohne Zugang zu euren Servern. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
