Seite 6 - PHPUnit

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.

Magento-Cronjobs muessen nicht ueber die vollstaendige Cron-Ausfuehrung getestet werden: Ruft man die Job-Klasse direkt auf und trennt Zeitsteuerung von Geschaeftslogik, laesst sich jeder Cronjob als gewoehnlicher PHPUnit-Test behandeln.

Eine Testsuite mit wenigen hundert Tests laeuft in Sekunden komplett durch, und niemand denkt ueber Teilmengen nach. Sobald ein Projekt aber auf mehrere tausend Tests waechst, wird die vollstaendige Ausfuehrung bei jeder kleinen Aenderung unpraktisch. PHPUnits @group-Attribute und der --filter-Parameter der Kommandozeile erlauben es, gezielt nur die Tests laufen zu lassen, die fuer die aktuelle Aenderung relevant sind, etwa nur schnelle Unit-Tests oder nur ein bestimmtes Modul, vorausgesetzt, ein Team einigt sich auf eine konsistente Taxonomie.

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.

Ein kompletter Reindex-Lauf ist fuer einen Test viel zu langsam und zu grobkoernig. Wer die eigentliche Indexer-Logik in eine separate Klasse auslagert und direkt mit praeparierten Eingabedaten aufruft, testet in Millisekunden statt Minuten.

Ein fehlgeschlagener parametrisierter Test, der nur 'Data set #7' meldet, zwingt zum Aufklappen des Data Providers und manuellen Nachzählen. Mit benannten Arrays statt nummerierter Indizes zeigt PHPUnit stattdessen sofort, welcher fachliche Fall gescheitert ist. Dieser Artikel zeigt an einem echten Vorher-Nachher-Beispiel, wie sich Named Datasets etablieren und was dabei an Fallstricken lauert.

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.