Seite 4 - PHPUnit

Wer Magento-Module ohne Integrationstests entwickelt, merkt Regressionen erst im Staging oder in der Produktion. Das Magento Test Framework bietet eine vollständige Umgebung mit echter Datenbankisolation, automatischer Fixture-Verwaltung und dem gesamten Magento-DI-Container – vorausgesetzt, man richtet es korrekt ein.

Wer Magento-Code ohne Tests schreibt, merkt bei jedem Refactoring, wie fragil die Abhängigkeiten wirklich sind. PHPUnit-Tests für Repositories, Service-Contracts und ViewModels decken die Logik der wichtigsten Schichten ab – ohne den vollständigen Magento-Bootstrap zu benötigen

Beispielbasierte Tests prüfen nur die Fälle, die dem Entwickler eingefallen sind. Property-based Testing dreht den Ansatz um: statt konkreter Eingaben formuliert man Invarianten – Eigenschaften, die für jede denkbare Eingabe gelten müssen – und lässt die Bibliothek Tausende zufälliger Gegenbeispiele suchen.

Wer ein gewachsenes PHP-Projekt auf PHPUnit 10 oder 11 hebt, begegnet einer Flut von Deprecation-Notices, geänderten Assertion-Signaturen und entfernten Interfaces. Dieser Artikel zeigt einen strukturierten Weg durch die Migration – ohne die laufende Testsuite zu gefährden und ohne jede Testklasse auf einmal anfassen zu müssen.

Tests, die einzeln bestehen aber gemeinsam fehlschlagen, sind das frustrierendste Problem in einer PHPUnit-Suite. Dahinter stecken fast immer globaler Zustand, fehlende Isolation oder versteckte Abhängigkeiten zwischen Tests – Probleme, die mit der richtigen Methodik aufdeckbar und dauerhaft behebbar sind.

Wer PHP in Docker-Containern entwickelt und trotzdem Tests direkt aus der IDE heraus starten will, steht vor einer Konfigurationsaufgabe: PhpStorm muss wissen, welcher PHP-Interpreter im Container steckt, wie Xdebug erreichbar ist und wie Pfade zwischen Host und Container gemappt werden. Dieser Artikel zeigt den vollständigen Weg.

Drei Tests, die dasselbe prüfen – nur mit unterschiedlichen Eingabewerten – sind kein Zeichen guter Testabdeckung. Sie sind technische Schulden. DataProvider lösen dieses Problem elegant: Eine Test-Methode, viele Datensätze, jeder als separater, benannter Testfall. Richtig eingesetzt reduzieren DataProvider Duplizierung und erhöhen Lesbarkeit gleichzeitig.

Dateisystem-Operationen gehören zu den am häufigsten untesteten Teilen von PHP-Anwendungen. Wer direkt mit file_get_contents() und file_put_contents() arbeitet, schreibt Code, der entweder gar nicht getestet wird oder Tests hinterlässt, die echte Dateien erzeugen, Reihenfolge-Abhängigkeiten haben und beim Parallelausführen brechen. vfsStream, Stream-Wrapper und Filesystem-Abstraktion lösen das Problem grundlegend.

Magento-Integrationstests mit XML-Fixtures sind fragil, schwer wartbar und kaum lesbar. PHP-basierte Fixtures, DataBuilder-Pattern und konsequente Nutzung des ObjectManagers erzeugen Testdaten, die lesbar, zuverlässig und einfach anpassbar sind – ohne Fixture-Dateien, die nach jedem Schema-Update brechen.

Tests, die von der aktuellen Uhrzeit, zufällig generierten UUIDs oder Pseudozufallswerten abhängen, sind flaky: Sie schlagen manchmal fehl, manchmal nicht, und die Ursache ist schwer zu reproduzieren. Clock-Interfaces, UUID-Factories und kontrollierter Zufall lösen dieses Problem grundlegend – ohne den Produktionscode zu komplizieren.