Seite 8 - Testing/E2E

Wer Jest ohne saubere TypeScript-Anbindung einsetzt, verliert die entscheidenden Vorteile von Typsicherheit genau dort, wo Fehler am teuersten sind, nämlich in Tests und Mocks. Dieser Artikel zeigt, wie sich ts-jest und babel-jest unterscheiden, wie jest.config.ts typsicher aufgesetzt wird und wie Mock-Funktionen, Modul-Mocks und Klassen-Mocks mit echten Typen statt any geschrieben werden.

Ein E2E-Test, der beim Laden einer Seite unweigerlich auch auf ein echtes Tracking-Skript, ein eingebettetes Chat-Widget oder ein externes Payment-Skript wartet, übernimmt automatisch die gesamte Instabilität, Ladezeit und Rate-Limitierung dieser fremden, vom eigenen Team nicht kontrollierten Systeme, obwohl der eigentliche Testfall mit diesen Drittanbieter-Diensten inhaltlich meist gar nichts zu tun hat. Gezieltes Blockieren oder, wo tatsächlich notwendig, gezieltes Mocken externer Skripte entkoppelt die Teststabilität von der Zuverlässigkeit dieser fremden Systeme und beschleunigt Testläufe spürbar.

Ein grüner End-to-End-Test beweist nicht, dass alle Consumer einer Symfony API weiterhin funktionieren, wenn sich ein Response-Feld ändert. Contract Testing macht die Erwartungen jedes Consumers explizit und prüft sie automatisch gegen den echten Provider, lange bevor ein Breaking Change in Produktion Schaden anrichtet.

Ein funktionaler E2E-Test bestätigt, dass ein Checkout mit einem einzelnen, isolierten Nutzer korrekt abläuft, sagt aber nichts darüber aus, was passiert, wenn zweihundert Nutzerinnen und Nutzer gleichzeitig denselben Checkout durchlaufen. Genau diese Lücke schließt Lasttesting mit k6, einem quelloffenen, skriptbasierten Lasttest-Werkzeug, das realistische, parallele Nutzerlast simuliert und dabei präzise Kennzahlen zu Antwortzeiten, Fehlerraten und Durchsatz liefert, lange bevor ein echter Sale-Ansturm diese Grenzen im Produktivbetrieb schmerzhaft aufdeckt.

Mocks sagen nur, ob das Frontend mit einer angenommenen API-Antwort korrekt umgeht, nicht ob diese Annahme noch stimmt. Contract Testing mit Pact.js schließt genau diese Lücke: Das Frontend definiert seine Erwartungen als ausführbaren Vertrag, und das Backend verifiziert automatisch, ob es diesen Vertrag tatsächlich erfüllt.

Mobile Shops leben von Touch-Gesten: Wischen durch Bildergalerien, Antippen von Filterschaltern, Ziehen von Off-Canvas-Menüs. Wer diese Interaktionen nur mit simulierten Mausklicks testet, übersieht Ghost-Clicks, blockierte Scrollrichtungen und Hover-Menüs, die auf einem Touchscreen nie erreichbar sind. Dieser Artikel zeigt, wie echte Touch-Events in Cypress und Playwright zuverlässig simuliert werden.

Ein Test ist nur so aussagekräftig wie die Daten, mit denen er läuft. Claude hilft bei der Testdatengenerierung, indem es realistische, strukturell konsistente und gezielt fehlerhafte Datensätze erzeugt, von einzelnen Fixtures bis zu Massendaten für Performance-Tests, ohne echte Kundendaten zu verwenden.

Ein Cookie-Consent-Banner wird in vielen Projekten einmalig eingerichtet, optisch abgenommen und danach kaum noch als eigenständiger, testwürdiger Funktionsbereich betrachtet, obwohl genau dieser Bereich einen unmittelbaren rechtlichen Bezug hat: Ladet ein Tracking-Skript trotz aktiv abgelehnter Zustimmung, handelt es sich nicht um eine kosmetische Kleinigkeit, sondern um einen tatsächlichen Verstoss gegen die Datenschutz-Grundverordnung mit möglichen Bussgeldfolgen. Ein automatisierter E2E-Test, der verschiedene Consent-Zustände gezielt simuliert und das tatsächliche Laden von Tracking-Skripten je nach Zustand überprüft, macht diese rechtlich relevante Funktionalität ebenso zuverlässig regressionssicher wie jeden anderen kritischen Geschäftsprozess im Shop.

Wachsende End-to-End-Testsuiten verlangsamen jede CI-Pipeline, wenn Tests sequentiell laufen. Dieser Artikel zeigt, wie ihr Testsuiten über mehrere CI-Worker verteilt, Lastverteilung anhand echter Laufzeiten statt reiner Dateianzahl optimiert, Ressourcenkonflikte bei gemeinsamen Datenbanken und Sandbox-Accounts vermeidet und mit Cypress Cloud, Playwright Sharding sowie GitLab-CI-Matrix-Jobs spürbar schnellere Testläufe erreicht.

Wer Magento-Anwendungen ohne systematische Sicherheitsprüfung entwickelt, verlässt sich auf Zufallsfunde statt auf Werkzeuge, die Schwachstellen zuverlässig aufdecken. Statische Analyse mit PHPStan und Psalm findet gefährliche Datenflüsse direkt im Quellcode, während dynamische Scanner wie OWASP ZAP echte Angriffe gegen eine laufende Staging-Umgebung fahren. Dieser Artikel zeigt, wie beide Ansätze zusammenwirken, wo ihre Grenzen liegen und wann sich welche Investition lohnt.