PHPUnit

Ein Test, der bei jeder Implementierungsänderung rot wird, ohne dass sich das beobachtbare Verhalten geändert hat, ist kein Test – er ist ein Hindernis. Overspecified Mocks, das Testen eigener Klassen über Mocks, Spy-Missbrauch und Expectation-Overload sind die häufigsten Ursachen für brittle PHPUnit-Suites, die mehr Wartungsaufwand erzeugen als Sicherheit liefern.

Die häufigste Erfahrung in PHP-Projekten: Tests sind schwierig zu schreiben, weil der Produktionscode es schwierig macht. Neue Abhängigkeiten direkt instanziiert, globaler State, zu viele Aufgaben in einer Klasse. Testbarkeit ist kein Zufallsprodukt – sie ist das Ergebnis konkreter Designentscheidungen im Produktionscode.

Direkte Aufrufe von new DateTime() oder time() sind der klassische Grund, warum zeitabhängige Logik schwer zu testen ist. Eine eigene Clock-Abstraktion löst das Problem an der Wurzel und erlaubt es, feste Zeitpunkte in PHPUnit-Tests zu setzen.

CLI-Commands sind oft der am wenigsten getestete Teil einer PHP-Anwendung. Dabei sind es genau diese Commands, die Cron-Jobs, Migrations, Deployments und kritische Batch-Operationen steuern. Exit-Codes sind der einzige Kommunikationskanal zwischen einem Prozess und dem aufrufenden System – und sie müssen korrekt sein, damit CI-Pipelines und Orchestratoren auf Fehler reagieren können.

Adminhtml-Controller vereinen Zugriffskontrolle, Formularverarbeitung und Redirect-Logik an einer Stelle, weshalb sich Unit- und Integrationstests ergaenzen muessen, um sowohl die reine Logik als auch das Zusammenspiel mit dem Magento-Backend-Stack abzudecken.

Hundert Prozent Code Coverage sagt nichts darüber aus, ob Tests tatsächlich Bugs erkennen würden. Mutation Testing mit Infection schleust künstlich kleine Fehler in den Symfony Code ein und prüft, ob die Testsuite jeden einzelnen davon zuverlässig auffängt.

Wer HTTP-Clients testet, ohne echte Netzwerkaufrufe auszufuehren, braucht realistische Test Doubles. Der Guzzle MockHandler erlaubt es, Erfolgsantworten, Fehlerstatus, Timeouts und kaputte JSON-Payloads praezise zu simulieren und so alle Codepfade eines Clients zuverlaessig abzudecken.

80% Line-Coverage klingt gut. Aber Line-Coverage sagt nichts darüber aus, ob die richtigen Fälle getestet werden. Ein Zweig, der bei einem bestimmten Eingabewert ausgeführt wird, zählt als abgedeckt – egal ob der andere Zweig je getestet wird. Coverage ist ein Werkzeug, kein Ziel. Wer es als Vanity-Metrik behandelt, optimiert die Zahl statt die Qualität.

Mehrere Plugins auf derselben Methode haengen still von der sortOrder in di.xml ab. Ein Test, der die tatsaechliche Ausfuehrungsreihenfolge dokumentiert, verhindert, dass ein neues Plugin unbemerkt eine bestehende Reihenfolge und damit das Verhalten kippt.

Manche Tests lassen sich nur sauber schreiben, wenn PHPUnit sie in einem komplett neuen PHP-Prozess ausfuehrt: etwa wenn Legacy-Code Konstanten definiert, die nicht neu gesetzt werden koennen, oder wenn statische Zustaende so tief verwoben sind, dass ein Reset in tearDown nicht ausreicht. @runInSeparateProcess loest dieses Problem zuverlaessig, aber nicht kostenlos: Jeder isolierte Test startet einen eigenen PHP-Interpreter, was die Laufzeit einer Suite spuerbar in die Hoehe treiben kann, wenn man es zu grosszuegig einsetzt.