Seite 2 - PHPUnit

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.

Ein Legacy-Projekt ohne jede Testabdeckung wirkt wie eine Mauer ohne Angriffspunkt. Mit Characterization Tests als Startpunkt, einer klaren Priorisierung nach Risiko und realistischen Meilensteinen laesst sich schrittweise eine belastbare PHPUnit-Baseline aufbauen, ohne das Team mit einem unrealistischen Alles-oder-Nichts-Ziel zu ueberfordern.

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.

PHPUnit hat seit Version 10 einen klaren Kurs eingeschlagen: Die alten @annotation-Docblocks werden schrittweise durch echte PHP-8-Attribute wie #[Test], #[DataProvider] und #[Group] ersetzt. Wer heute noch mit Annotationen arbeitet, verschenkt Typsicherheit, IDE-Unterstützung und eine sauberere Fehlerdiagnose. Dieser Artikel zeigt, warum sich der Umstieg lohnt und wie eine bestehende Testsuite Schritt für Schritt migriert wird.

Wer Exceptions nicht gezielt testet, lässt Fehlerbehandlung ungeprüft – der gefährlichste blinde Fleck in einer PHP-Testsuite. PHPUnit bietet präzise Methoden, um sicherzustellen, dass der richtige Ausnahmetyp, die passende Nachricht und der korrekte Fehlercode ausgelöst werden.

Die meisten PHP-Projekte haben entweder zu viele Unit Tests für Code, der von Datenbankzuständen abhängt, oder zu wenige Tests auf der richtigen Ebene. Die Testpyramide ist kein akademisches Konzept, sondern ein praktisches Werkzeug für die Entscheidung, welcher Testtyp welches Problem am effizientesten löst.