Seite 3 - Testing/E2E

Wer React-Komponenten testet, die Daten laden, steht vor derselben Frage: fetch mocken oder gegen ein echtes Backend testen. MSW (Mock Service Worker) fängt Netzwerk-Requests auf Protokollebene ab, sodass Komponenten genau den Code ausführen, den sie auch in Produktion nutzen, während die Antworten vollständig kontrolliert bleiben.

Cypress-Tests, die lokal zuverlässig grün sind, scheitern in der CI oft unerwartet an Ressourcenlimits, abweichenden Viewports und Timing-Unterschieden auf geteilten Runnern. Dieser Artikel zeigt, wie ihr Cypress in GitLab CI und GitHub Actions headless ausführt, Video- und Screenshot-Artefakte bei Fehlschlägen sichert, node_modules und die Cypress-Binary cacht und Testläufe über mehrere Jobs hinweg parallelisiert.

Die meisten Testverfahren prüfen, ob ein System unter erwarteten, sauberen Bedingungen korrekt funktioniert, während Chaos Engineering den umgekehrten Weg geht und gezielt, kontrolliert Fehler in ein laufendes System einbringt, etwa den Ausfall eines Services, erhöhte Netzwerklatenz oder den Verlust einer Datenbankverbindung, um zu beobachten, wie widerstandsfähig das Gesamtsystem tatsächlich auf diese Störung reagiert. Diese Disziplin geht davon aus, dass komplexe, verteilte Systeme früher oder später ohnehin ausfallen werden, und macht daraus die bewusste Entscheidung, diesen Ausfall lieber kontrolliert und zu einem selbst gewählten Zeitpunkt zu erleben als unkontrolliert mitten in der Nacht wegen eines echten Vorfalls.

Wer für jede Sprache und jeden Store eine eigene Testkopie pflegt, verliert Übersicht und Laufzeit gleichzeitig. Ein Store-Kontext-Parameter in Cypress oder Playwright reicht aus, um Sprachen, Währungen und Katalogunterschiede gezielt zu prüfen und typische Store-Scope-Konfigurationsfehler zuverlässig vor dem Go-Live abzufangen.

Eine Bestellbestätigung oder eine Registrierungsmail gehört zu den kritischsten, aber am häufigsten ungetesteten Pfaden eines Onlineshops, weil E-Mail-Versand außerhalb des direkten Zugriffs eines Browsertests stattfindet und asynchron, mit unbekannter Verzögerung, in einem fremden System landet. Ein Test-SMTP-Server wie Mailhog oder Mailtrap löst genau dieses Problem, indem er ausgehende E-Mails innerhalb der Testumgebung abfängt, über eine eigene API abrufbar macht und damit Inhalt, Betreff und Links einer E-Mail genauso präzise prüfbar macht wie ein DOM-Element im Browser.

Ein CSS Refactoring verschiebt den Warenkorb Button drei Pixel nach links, alle Unit und Funktionstests bleiben grün, und trotzdem sieht der Checkout plötzlich kaputt aus. Visual Regression Testing schließt genau diese Lücke, indem es Screenshots automatisch mit einer gespeicherten Baseline vergleicht, echte Layoutfehler von harmlosem Renderingrauschen unterscheidet und Entwickler zuverlässig warnt, bevor Kunden den Bruch bemerken.

Ein Datenbankschema veraendert sich ueber Jahre durch viele kleine Migrationen, und ohne systematische Regressionstests bleibt unklar, ob eine neue Aenderung stillschweigend eine bestehende Anwendung bricht. Schema-Snapshots, Contract-Tests und automatisierte Diff-Checks machen genau das sichtbar, bevor ein Deployment Schaden anrichtet.

MFTF automatisiert genau die Klasse von Fehlern, die Unit-Tests systematisch übersehen: kaputte Checkout-Flows, fehlerhafte JavaScript-Interaktionen und Admin-Formulare, die nach einem Update plötzlich nicht mehr speichern. Wer MFTF sauber aufsetzt, bekommt einen Browser-gestützten Absicherungslayer, der echte Klickpfade im Storefront und Backend automatisch nachstellt und Regressionen findet, bevor Kunden sie finden.

Wer E2E-Tests mit page.waitForTimeout oder festen Sleep-Aufrufen stabilisiert, bekämpft nur Symptome statt Ursachen. Playwright prüft vor jeder Aktion automatisch, ob ein Element sichtbar, stabil, aktiviert und tatsächlich klickbar ist, und wiederholt diese Prüfung, bis sie erfüllt ist oder ein Timeout erreicht wird. Dieser Artikel zeigt, wie diese Actionability-Checks funktionieren, warum feste Wartezeiten Flakiness verschleiern statt beheben und wie man Timeout-Fehler mit dem Trace Viewer gezielt diagnostiziert.

Eine Slack-Nachricht, die lediglich "Build fehlgeschlagen" meldet, ohne anzugeben, welcher Test betroffen war, seit wann das Problem besteht oder ob es sich überhaupt um eine bekannte Flakiness handelt, zwingt jede Empfängerin und jeden Empfänger zu einem Klick in die CI-Oberfläche, nur um die grundlegendste Frage zu beantworten, was eigentlich passiert ist. Eine durchdachte Slack-Integration liefert stattdessen bereits im Alert selbst genügend Kontext, um die Dringlichkeit sofort einschätzen zu können, während eine gezielte Filterung verhindert, dass das Team durch permanentes, letztlich ignoriertes Rauschen in eine gefährliche Alert-Fatigue gerät.