Seite 4 - Testing/E2E

Ein Lasttest, der über fünf Minuten eine hohe Anzahl gleichzeitiger Nutzer simuliert, bestätigt lediglich, dass ein System kurzfristig mit dieser Last umgehen kann, sagt aber nichts darüber aus, was passiert, wenn dieselbe, moderate Last über zwölf oder vierundzwanzig Stunden ununterbrochen anhält. Genau diese Frage beantwortet ein Soak-Test (auch Endurance-Test genannt), der eine realistische, aber konstante Last über einen deutlich längeren Zeitraum aufrechterhält, um schleichende Probleme wie Speicherlecks, langsam erschöpfte Ressourcen-Pools oder unkontrolliert wachsende Log-Dateien aufzudecken, bevor sie in Produktion nach Stunden stabilen Betriebs plötzlich zuschlagen.

Wer Login und Warenkorb-Schritte in jeder Testdatei einzeln wiederholt, baut eine Cypress-Suite, die bei jeder UI-Änderung an dutzenden Stellen bricht. Custom Commands kapseln wiederkehrende Abläufe in wiederverwendbare, typsichere Bausteine und machen E2E-Tests für einen Magento-Shop lesbar, robust und wartbar.

Eine Testsuite, die formal mit 99 Prozent Erfolgsquote durchläuft, kann trotzdem massive, verborgene Probleme haben, etwa wenn dieselben drei Tests jede Woche wegen echter Flakiness manuell neu gestartet werden müssen oder die Gesamtlaufzeit über Monate hinweg unbemerkt von fünf auf fünfundvierzig Minuten gewachsen ist. Wer ausschließlich auf die binäre Grün-Rot-Anzeige eines einzelnen Laufs schaut, übersieht genau die Trends, die langfristig über die tatsächliche Nützlichkeit und Vertrauenswürdigkeit einer Testsuite entscheiden, weshalb ein durchdachtes Set an Metriken jenseits des reinen Bestehen-oder-Scheitern-Signals notwendig ist.

Snapshot Testing verspricht schnellen Schutz gegen unbeabsichtigte Änderungen an Vue-Komponenten, kippt aber in der Praxis häufig in bedeutungslose grüne Häkchen. Instabile Snapshots, gedankenloses Aktualisieren und fehlende Reviews verwandeln ein sinnvolles Werkzeug in eine Attrappe, die echte Regressionen unbemerkt durchwinkt.

Magento Admin Workflows wie Produktanlage, Bestellabwicklung und Preisregeln entscheiden über Umsatz und Datenintegrität, auch ohne dass Kunden sie je sehen. End to end Tests mit Cypress oder Playwright decken genau die Lücke ab, die PHPUnit Integrationstests offen lassen: Session Handling, Grid Interaktionen und Massenaktionen im echten Browser, mit klarer Priorisierung nach Wartungskosten und Geschäftsrisiko.

Vitest UI ersetzt die reine Terminal-Ausgabe durch ein interaktives Dashboard im Browser, mit Testfilter, Modul-Graph, Coverage-Heatmap und Snapshot-Diffs auf einen Blick. Wer in einem Vue-Projekt regelmäßig hunderte Tests durchsucht, findet über Vitest UI fehlgeschlagene Fälle und ungetestete Codepfade deutlich schneller als über gescrollte Konsolen-Logs.

Playwrights page.route()-API erlaubt es, jede einzelne Netzwerkanfrage einer Seite abzufangen, bevor sie tatsächlich an den Server geht, und wahlweise mit einer eigenen, kontrollierten Antwort zu beantworten, die tatsächliche Anfrage unverändert durchzulassen, oder sie vollständig zu blockieren. Diese Fähigkeit macht Route-Mocking zu einem der wirkungsvollsten Werkzeuge gegen die häufigste Ursache instabiler E2E-Tests: die Abhängigkeit von einem echten, möglicherweise langsamen oder inkonsistenten Backend-System.

Subagents delegieren fokussierte Teilaufgaben an einen separaten Claude-Code-Kontext mit eigenem Kontextfenster und eigenem Systemprompt. Das hilft bei paralleler Codebasis-Recherche und isolierten Review-Durchläufen, bringt aber Koordinationsaufwand mit sich, der sich für einfache Aufgaben nicht lohnt und einen einzelnen Agenten oft die bessere Wahl bleiben lässt.

Klassische Unit-Tests prüfen einzelne, von Hand ausgedachte Beispiele. Property-Based Testing dreht das Prinzip um: Statt Beispiele zu schreiben, definiert man Eigenschaften, die für jede gültige Eingabe gelten müssen, und lässt fast-check tausende zufällige Fälle generieren, um genau die Randfälle zu finden, die ein Mensch beim Schreiben von Tests übersieht.

Ein Bash-Skript, das auf dem eigenen Rechner klaglos läuft, kann auf dem Zielsystem scheitern, weil dort eine andere Coreutils-Version, ein fehlendes Tool oder eine abweichende Bash-Version installiert ist. Docker-Testcontainer machen diese Unterschiede reproduzierbar sichtbar und lassen sich in der CI-Pipeline wiederverwenden, statt bei jedem Lauf neu aufgesetzt zu werden.