Seite 2 - Testing/E2E

shUnit2 bringt den klassischen xUnit-Stil mit assertEquals und setUp/tearDown in die Bash-Welt, bats-core beschreibt Tests dagegen als lesbare @test-Blöcke im BDD-Stil. Beide Frameworks lösen dasselbe Grundproblem, aber mit unterschiedlicher Syntax, unterschiedlicher CI-Integration und unterschiedlichen Stärken je nach Projektgröße.

Der Checkout ist die wertvollste Strecke in jedem Magento-Shop und gleichzeitig die fragilste, weil hier Frontend-State, asynchrone AJAX-Aufrufe und externe Zahlungs-APIs zusammentreffen. Dieser Artikel zeigt, wie ihr Warenkorb, Versandarten, Zahlungsarten und die Bestellbestaetigung mit Cypress und Playwright end-to-end testet, Payment-Gateways im Sandbox-Modus zuverlässig simuliert und Gast- sowie Login-Pfade sauber voneinander trennt.

Wer GraphQL-APIs nur mit End-to-End-Tests absichert, bekommt eine langsame, brüchige Testsuite. Wer nur Unit-Tests schreibt, übersieht Fehler in der Schema-Komposition. Eine durchdachte GraphQL Testing Pyramide verteilt Testaufwand gezielt über Resolver-Ebene, Schema-Ebene und echte Nutzerflüsse, mit klaren Kriterien, welche Ebene welche Fehlerklasse abdeckt.

Sobald eine Anwendung bewusst einen neuen Tab öffnet, etwa für einen externen Zahlungsdienstleister wie PayPal, oder Zustand über mehrere gleichzeitig geöffnete Fenster hinweg synchron halten muss, reicht das klassische, auf ein einzelnes Fenster beschränkte E2E-Testmodell nicht mehr aus. Cross-Tab- und Multi-Window-Testing verlangt ein bewusstes, explizites Modell mehrerer, gleichzeitig aktiver Browser-Kontexte, das in Playwright deutlich natürlicher unterstützt wird als in Cypress, wo dieselbe Aufgabe historisch nur mit erheblichen Workarounds lösbar war.

Playwright hat sich neben Cypress als zweite zentrale Lösung für End to End Tests etabliert und bringt Multi Browser Support, einen eingebauten Trace Viewer und ein kostenloses Worker Modell direkt aus der Box mit. Dieser Artikel zeigt Installation, Konfigurationsdatei und einen ersten echten Test gegen einen Magento und Hyvä Storefront, damit Teams die Wahl zwischen Cypress und Playwright fundiert treffen können.

Teams stehen regelmäßig vor der Frage, wie viel in vollständige End-to-End-Tests und wie viel in isolierte Component Tests investiert werden sollte. Beide Ansätze prüfen unterschiedliche Ebenen der Anwendung, und wer sich für nur einen entscheidet, kauft sich blinde Flecken ein, die früher oder später als Produktionsbugs zurückkommen.

E2E-Tests und Penetration-Tests werden in Projektgesprächen gelegentlich so behandelt, als könnte eine ausreichend umfangreiche E2E-Testsuite einen eigenständigen Penetration-Test irgendwann überflüssig machen, was auf einem grundlegenden Missverständnis der jeweiligen Testabsicht beruht: Ein E2E-Test prüft, ob eine Anwendung entlang bekannter, vorab definierter Nutzerpfade wie erwartet funktioniert, während ein Penetration-Test gezielt versucht, die Anwendung auf Wegen zu missbrauchen, die kein Entwicklungsteam beim Schreiben der Testfälle vorher bedacht hat. Diese grundlegend unterschiedliche Denkrichtung macht beide Testarten zu sinnvollen, sich ergänzenden Bausteinen einer Qualitätssicherungs-Strategie, aber keine der beiden kann die jeweils andere strukturell ersetzen.

Wer API-Tests in einem separaten Tool pflegt und E2E-Tests in Cypress oder Playwright, verdoppelt Wartungsaufwand und verliert Kontext zwischen beiden Welten. Mit cy.request() und der Playwright APIRequestContext lassen sich Testdaten in Millisekunden statt über Formulare aufbauen, Auth-Sessions zwischen API und Browser teilen und ganze Testsuiten spürbar beschleunigen, ohne die Zuverlässigkeit zu verlieren.

Playwright zeichnet bei jedem fehlgeschlagenen Testlauf eine vollständige Aufzeichnung aus Screenshots, DOM-Snapshots, Netzwerkanfragen und Konsolenausgaben auf. Der Trace Viewer macht diese Aufzeichnung durchsuchbar und zeigt exakt, welcher Klick, welche Anfrage oder welcher Zustand einen Test scheitern ließ. So wird stundenlanges Rätselraten bei flaky Tests durch gezielte Fehlersuche ersetzt.

Tests, die einzeln zuverlässig bestehen, aber in der vollen Suite oder bei paralleler Ausführung plötzlich fehlschlagen, deuten fast immer auf geteilten Zustand zwischen Browser Storage, Datenbank und Testdaten hin. Dieser Artikel zeigt konkrete Isolationsstrategien für Cypress und Playwright, von eindeutigen Testdaten pro Worker bis zu sauberem Cleanup, damit E2E Suiten stabil, parallel sicher und reproduzierbar bleiben.