Seite 10 - Testing/E2E

Ein TypeScript-Typ, der fehlerfrei kompiliert, ist nicht automatisch korrekt. Komplexe generische und bedingte Typen können sich unbemerkt zu any verbreitern, ungültige Formen akzeptieren oder in einem Zweig falsch verengen. Tools wie tsd, expect-type und Vitests expectTypeOf machen genau dieses Verhalten testbar, rein zur Kompilierzeit, ohne dass ein einziger Runtime-Test dafür nötig ist.

Wer eine wachsende Cypress- oder Playwright-Suite bei jedem Commit komplett ausführt, verliert schnell wertvolle Minuten Feedback-Zeit und CI-Budget. Dieser Artikel zeigt praxisnah, wie Feature-Tags, Dependency-Graphen und Git-Diff-Heuristiken betroffene Tests zuverlässig identifizieren, während geplante Vollläufe weiterhin als Sicherheitsnetz gegen übersehene Regressionen dienen.

Hundert Prozent Code-Coverage bedeutet nur, dass jede Zeile einmal ausgeführt wurde, nicht dass ein Test einen echten Fehler auch bemerken würde. Mutation Testing dreht diese Frage um: Stryker verändert gezielt einzelne Codezeilen zu kleinen Bugs und prüft, ob eure Tests diese Mutanten tatsächlich erkennen und fehlschlagen, statt stillschweigend grün zu bleiben.

Wer End-to-End-Tests mit Cypress oder Playwright als Hauptabsicherung nutzt, zahlt mit langsamen Testläufen, hoher Flakiness und teurer Wartung. Die Testpyramide zeigt, warum die meiste Testabdeckung als schnelle, günstige Unit- und Integrationstests entstehen sollte, während E2E-Tests gezielt nur die kritischsten Nutzerpfade end to end absichern und dadurch Vertrauen schaffen, ohne die Continuous-Integration-Pipeline auszubremsen.

Ein fehlgeschlagener End-to-End-Test liefert im Standardfall lediglich eine Fehlermeldung und einen Stacktrace auf Ebene des Test-Frameworks, verrät aber nichts darüber, was im Backend während dieses konkreten Testlaufs tatsächlich passiert ist. Test-Observability schließt genau diese Lücke, indem sie Distributed Tracing, strukturierte Logs und Metriken mit dem jeweiligen Testlauf korreliert, sodass sich beim ersten Blick in einen roten Test sofort erkennen lässt, ob die Ursache im Frontend, in einer bestimmten Backend-Anfrage oder in einer Drittanbieter-Integration liegt, statt erst mühsam manuell nachvollziehen zu müssen, welcher Service zu welchem Zeitpunkt beteiligt war.

GraphQL-APIs brechen viele gewohnte REST-Testmuster: ein einziger Endpunkt, flexible Query-Formen und ein Statuscode, der fast immer 200 bleibt, selbst bei Fehlern. Wer Magento-Storefronts über GraphQL testet, braucht andere Assertions, robuste Snapshot-Strategien und einen klaren Blick auf das errors-Array, um Warenkorb-Mutationen, Produktsuchen und Checkout-Flows zuverlässig abzusichern.

Ein Bug, der sich lokal partout nicht reproduzieren lässt, aber in Produktion regelmäßig auftritt, ist eines der frustrierendsten Probleme im Magento-Alltag. Mit systematischer Eingrenzung, sicherem Remote-Debugging und strukturiertem Logging wird auch der hartnäckigste Produktions-Only-Bug greifbar.

Testcode bekommt oft einen Freifahrtschein bei der Typsicherheit, weil Deadlines drücken, ein Mock schnell kopiert wird oder es ja angeblich nur ein Test ist. Dabei sollen gerade Tests Typregressionen im getesteten Code zuverlässig aufdecken. Dieser Artikel zeigt praxistaugliche typisierte Mocking-Patterns mit vi.mocked, satisfies und Mock-Factories sowie unknown und zod als Ersatz für any bei losen Testdaten.

Zwei Teams, die beide End-to-End-Tests für ihre Symfony-Anwendung brauchen, können bei der Wahl des Tools zu vollkommen unterschiedlichen, jeweils richtigen Antworten kommen. Panther schreibt Browser-Tests als gewöhnlichen PHPUnit-Code mit echtem Browser im Hintergrund, wovon vor allem Entwickler profitieren, die ohnehin in PHP denken. Behat beschreibt dieselben Szenarien in der lesbaren Gherkin-Syntax, die auch ein Product Owner ohne Programmierkenntnisse verstehen und sogar mitschreiben kann. Dieser Artikel vergleicht beide Werkzeuge entlang der Fragen, die in der Praxis tatsächlich den Ausschlag geben: Lesbarkeit, Entwickler-Tempo, Wartungsaufwand und die Frage, ob man wirklich nur eins von beiden braucht.

Ein Flaky Test, der abwechselnd besteht und fehlschlägt, ohne dass sich am Code etwas ändert, untergräbt das Vertrauen in die gesamte CI-Pipeline. Claude hilft bei der Root Cause Analyse, indem es Logs, Stacktraces und Muster aus wiederholten Läufen systematisch auswertet und typische Ursachen wie Race Conditions oder Test-Isolation-Fehler eingrenzt.