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.

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.

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.

Ein halbherzig eingerichtetes PHPUnit-Projekt verlangsamt jeden Entwickler-Workflow: fehlende Autoload-Pfade, fehlendes Bootstrap, keine Trennung von Unit- und Integrationstests. Dieses Tutorial zeigt, wie ein sauberes Setup von Anfang an aussieht – reproduzierbar, teamfähig und CI-ready.

Magento-Plugins und Observer sind mächtige Erweiterungspunkte, aber ihre enge Kopplung an den Magento-ObjectManager macht sie schwer testbar. Mit dem richtigen Refactoring-Ansatz lässt sich die Kernlogik aus jedem Plugin oder Observer extrahieren und isoliert mit PHPUnit testen – ganz ohne Magento-Bootstrap.

Tests, die nur lokal ausgeführt werden, schützen das Projekt nicht. Erst die Integration in CI/CD macht Testautomatisierung zum Qualitätsgatter – jeder Pull Request wird automatisch geprüft, Coverage-Berichte werden als Artefakte gespeichert und Fehler werden dort gemeldet, wo sie entstehen: im Code, nicht erst beim Deploy. Dieser Artikel zeigt die vollständige CI/CD-Integration von PHPUnit für beide großen Plattformen.

Wer PHPUnit nur über die Kommandozeile ausführt, verschenkt einen Großteil der PhpStorm-Produktivität. Run Configurations, Coverage-Berichte direkt im Editor, Test-Filter auf einzelne Methoden und der Docker-Remote-Interpreter verwandeln PhpStorm in eine vollständige Testumgebung – ohne das Terminal zu verlassen.

Repository-Tests mit Mocks prüfen die falsche Schicht. Ein Mock-Repository kann kein SQL-Syntax-Problem, kein Index-Problem und keinen N+1-Bug entdecken. Echter Datenbankzugriff in Tests ist teuer – aber an den richtigen Stellen unersetzlich. Die Kunst liegt darin, zu wissen, wo genau diese Stellen sind und wie man Datenbankisolation zuverlässig umsetzt.

Eine langsame, unstrukturierte Test-Suite ist keine Test-Suite – sie ist ein Bremsklotz. Diese Checkliste deckt alle Stellen auf, an denen PHPUnit-Setups Zeit, Wartbarkeit und Entwicklervertrauen verlieren, und gibt zu jedem Punkt eine direkt umsetzbare Maßnahme.