Seite 4 - PHPUnit

Ein Store-Scope-Bug faellt oft erst live auf, weil Tests nur den Default-Store kennen. Wer ScopeConfigInterface gezielt mockt, deckt Store- und Website-Abweichungen ab, ohne fuer jeden Store echte Fixtures in der Datenbank zu pflegen.

Parallele PHPUnit-Läufe sparen Zeit – aber sie stellen Anforderungen an Datenbankisolation, Fixture-Design und Konfiguration, die viele Teams erst nach dem ersten schmerzhaften Race Condition treffen. Dieser Artikel zeigt, wie paratest korrekt eingerichtet wird, warum Shared State die häufigste Fehlerquelle ist und wie man Test-Suites wirklich parallel-sicher macht.

Magento-Consumer laufen asynchron gegen RabbitMQ, doch die eigentliche Verarbeitungslogik dahinter laesst sich vollstaendig synchron und ohne laufenden Broker testen, wenn man Consumer-Klasse und Domaenenlogik sauber trennt.

Magentos REST-API basiert auf Service Contracts, die in webapi.xml deklariert werden, doch nichts verhindert im Alltag, dass eine Implementierung im Laufe der Zeit unbemerkt vom deklarierten Interface abweicht. Automatisierte Vertragstreue-Tests schliessen genau diese Luecke.

Manche Tests scheitern nicht, weil der getestete Code fehlerhaft ist, sondern weil sie von Faktoren abhaengen, die sich der Kontrolle des Tests entziehen: Netzwerklatenz, Timing-Fenster oder externe Dienste mit gelegentlichen Aussetzern. Retry-Plugins wiederholen einen fehlgeschlagenen Test automatisch, bevor sie ihn endgueltig als rot werten, und koennen so eine instabile CI-Pipeline kurzfristig stabilisieren. Wer Retry aber als dauerhafte Loesung statt als befristete Uebergangsmassnahme einsetzt, verschiebt echte Probleme nur in eine bequeme Grauzone.

Architekturregeln, die nur in Dokumenten existieren, werden gebrochen. Mit PHPUnit, PHP-Arch und der Reflection API lassen sich Schichtengrenzen, Modulabhängigkeiten und Designregeln als ausführbare Tests formulieren – die sofort anschlagen, wenn eine Klasse die falsche Schicht aufruft oder ein Modul eine verbotene Abhängigkeit einführt.

Code Coverage klingt nach einem einfachen Konzept, wird aber in großen Magento 2 Projekten schnell zur Bremse: Xdebug verlangsamt die Test-Suite um Faktor 5 bis 10, Reports sind riesig, und ohne Konfiguration misst man das Falsche. PCOV, gezielte Whitelist-Konfiguration und CI-Schwellenwerte machen Coverage zu einem nützlichen Werkzeug statt einem Engpass.

Wer Legacy-Code refactorn will, aber keine Tests hat, steht vor einem Henne-Ei-Problem: Tests schreiben erfordert Verständnis des Codes, Verständnis erfordert Lesen des Codes, aber Sicherheit beim Ändern erfordert Tests. Golden Master Tests lösen diesen Knoten – sie testen das Verhalten, bevor es verstanden wird.

In Magento 2 gibt es drei grundlegend verschiedene Test-Typen mit sehr unterschiedlichen Laufzeiten, Wartungskosten und Einsatzbereichen. PHPUnit für Unit- und Integrationstests, MFTF für End-to-End-Browser-Tests und REST-API-Tests für die Webservice-Schicht. Die häufigsten Fehler in Magento-Test-Strategien: zu viele MFTF-Tests, zu wenige Unit Tests, und API-Tests, die eigentlich Logik-Tests sein sollten.

Tests direkt in der IDE mit einem Klick oder Tastenkürzel auszuführen, ohne die Konsole zu öffnen, ist ein Produktivitätsgewinn, der schnell zur selbstverständlichen Arbeitsweise wird. PhpStorm unterstützt PHPUnit für Docker-basierte Magento-Setups vollständig – wenn der Remote-Interpreter und die Run Configuration korrekt konfiguriert sind. Dieser Artikel führt durch den vollständigen Setup-Prozess.