Seite 5 - Testing/E2E

Flaky Tests sind End-to-End-Tests, die ohne Codeänderung mal grün und mal rot laufen, und sie untergraben das Vertrauen in die gesamte Testsuite. Die Ursachen liegen fast immer in Timing-Problemen, geteiltem Testzustand, Netzwerkabhängigkeiten oder fragilen Selektoren. Dieser Artikel zeigt, wie man diese Ursachen systematisch findet, robuste Cypress- und Playwright-Patterns einsetzt und flaky Tests kontrolliert quarantänisiert, statt sie stillschweigend zu ignorieren.

Playwright testet Vue-Anwendungen als Ganzes im echten Browser, mit Auto-Waiting statt fester Timeouts, mit Netzwerk-Interception statt echtem Backend und mit paralleler Ausführung über mehrere Browser-Engines hinweg. Das macht End-to-End-Tests planbar statt zur Quelle ständiger CI-Flakiness.

Datenintegritaet, die nur bei Bedarf manuell nachgeprueft wird, ist bereits verletzt, bevor jemand hinschaut. Automatisierte Pruefungen aus Constraints, Checksummen und statistischen Anomalie-Checks decken Inkonsistenzen auf, lange bevor sie zu falschen Berichten oder fehlerhaften Geschaeftsentscheidungen fuehren.

Ein GraphQL-Schema ist bereits ein maschinenlesbarer Vertrag zwischen Frontend und Backend. Mit einem Mock Schema wird dieser Vertrag ausführbar: Frontend-Teams entwickeln gegen realistische Testdaten, lange bevor das Backend fertig ist, und Breaking Changes fallen automatisiert auf, statt erst in Production.

Automatisierte Scanner finden nur einen Bruchteil der Barrieren einer Webanwendung, und manuelle Prüfung ist zeitaufwendig. Claude hilft bei Barrierefreiheitstests, indem es ARIA-Struktur analysiert, Testfälle für Tastaturbedienung generiert und Screenreader-Szenarien durchdenkt, als Ergänzung zu automatisierten Tools und menschlicher Prüfung.

Der Login-Prozess ist für praktisch jede Magento-Anwendung der Eintrittspunkt zu allen personalisierten Funktionen, vom Bestellverlauf über gespeicherte Adressen bis zum Wunschzettel, und gleichzeitig einer der am häufigsten stillschweigend kaputten Bereiche einer Testsuite, weil Login-Tests besonders anfällig für verwaiste Testnutzer, abgelaufene Test-Sessions und versehentlich eingecheckte Zugangsdaten sind. Ein sauber aufgebauter Authentifizierungs-Testflow behandelt Login, Logout, Session-Timeout und Zwei-Faktor-Authentifizierung als eigenständige, klar voneinander getrennte Testfälle mit einer durchdachten Testnutzer-Verwaltung im Hintergrund, statt alle Aspekte in einem einzigen, unübersichtlichen Testfall zu vermischen.

Hyvä hat keine Knockout-Viewmodels und damit auch keine klassische JavaScript-Unit-Test-Ebene, die man aus Luma-Themes kennt. Wer eine Teststrategie für Hyvä-Themes aufbaut, muss die Testpyramide deshalb neu denken: PHPUnit prüft die PHP-Logik hinter den ViewModels, PHPStan fängt Typfehler ab, bevor überhaupt ein Test läuft, und Playwright deckt genau die Alpine.js-Interaktion im echten Browser ab, für die es in Hyvä sonst keine sinnvolle Unit-Test-Ebene gibt.

Eine Testsuite, die über Jahre organisch mit dem Produktivcode mitwächst, sammelt fast zwangsläufig dieselben Arten von Verfall an wie der Produktivcode selbst: kopierte Testfälle, die sich nur in einem einzigen Wert unterscheiden, veraltete Hilfsfunktionen, die niemand mehr traut zu löschen, und Setup-Blöcke, die von Testfall zu Testfall fast identisch, aber nie ganz gleich sind. Anders als beim Produktivcode fehlt für Testcode-Refactoring aber ein entscheidendes Sicherheitsnetz: Es gibt keine zweite Testsuite, die prüfen würde, ob die erste noch korrekt funktioniert, weshalb Refactoring an Tests selbst mit besonderer Sorgfalt geschehen muss.

Wer Datenbank-Migrationen ungetestet gegen Produktion fahren laesst, riskiert Datenverlust, lange Downtime und stille Inkonsistenzen. Mit einer klaren Teststrategie aus Expand-Contract-Pattern, Rollback-Proben und automatisierten Pipelines werden Schema-Aenderungen planbar statt riskant.

Ein einzelner KI-Review-Durchlauf versucht meist, Sicherheit, Performance, Stil und Architektur gleichzeitig zu bewerten, und bleibt dabei in jedem einzelnen Bereich oberflächlich. Parallele Code Reviews mit spezialisierten Agenten, die jeweils nur einen Aspekt gründlich prüfen, liefern tiefere Erkenntnisse in kürzerer Wartezeit, sofern die Ergebnisse anschließend sauber zusammengeführt werden.