Seite 3 - PHPUnit

PHPUnit führt vier verschiedene Lifecycle-Hooks in einer festen Reihenfolge aus, zwei davon einmal pro Klasse, zwei davon vor und nach jedem einzelnen Test. Wer diese Reihenfolge nicht präzise kennt, baut leicht Tests, die scheinbar isoliert wirken, tatsächlich aber Zustand über static-Eigenschaften miteinander teilen. Dieser Artikel geht die komplette Kette durch, mit den typischen Fehlern und wann static- statt Instanz-Methoden nötig sind.

Wer jeden Collaborator blind als Mock behandelt, verliert die semantische Aussagekraft seiner Tests. Stub, Fake, Spy, Mock und Dummy haben klar definierte Rollen – und wer diese Rollen verwechselt, schreibt Tests, die Fehler verbergen statt aufzudecken.

REST-APIs und DTO-Mapping sind zwei der häufigsten Fehlerquellen in PHP-Projekten – und zwei der am schwersten zu testenden Bereiche, wenn die Strategie fehlt. Contract Tests, Schema-Validierung und saubere HTTP-Stubbing-Patterns machen API-Tests reproduzierbar, schnell und aussagekräftig.

Magento 2 exponiert komplexe Geschäftslogik über REST und GraphQL APIs. Wer Custom-Endpoints, Schema-Erweiterungen oder API-Policies implementiert, braucht verlässliche Integrationstests – kein manuelles Postman-Testen, kein "läuft auf Staging, hoffe auf das Beste".

Snapshot-Tests klingen verlockend: einmal ausführen, Ergebnis speichern, fertig. Doch in der Praxis entwickeln sie sich schnell zur Wartungslast, wenn man nicht genau versteht, für welche Szenarien sie geeignet sind und welche Disziplin im Team dafür notwendig ist.

100% Code Coverage bedeutet nicht, dass Tests wirklich prüfen. Infection führt automatische Mutationen in den Produktionscode ein und misst, ob PHPUnit-Tests diese Fehler erkennen. Der Mutation Score Index ist die ehrlichste Qualitätsmetrik, die man einer Testsuite anlegen kann.

Grüne Tests bedeuten nicht, dass Code sicher ist. In vielen Teams werden Tests im Review nur oberflächlich begutachtet – ob sie laufen, ob Coverage-Zahlen stimmen. Dabei sind es ganz andere Kriterien, die entscheiden, ob ein PHPUnit-Test echten Schutz vor Regressionen bietet oder nur Sicherheit vortäuscht.

Das Debugging von PHPUnit-Tests in einer Docker-Umgebung mit PhpStorm ist einer der frustrierendsten Punkte in der PHP-Entwicklung. Die Konfiguration scheitert oft an XDEBUG_MODE, falschem Path-Mapping oder einem nicht korrekt konfigurierten Remote-Interpreter. Diese Anleitung zeigt den vollständigen Weg – von der Xdebug-Installation bis zu laufenden Coverage-Reports.

Eine PHPUnit-Suite, die zwanzig Minuten läuft, wird im Team ignoriert. Tests werden nicht mehr lokal ausgeführt, Feedback-Loops werden länger und die Qualitätssicherung landet ausschließlich in der CI-Pipeline – zu spät. Dieser Artikel zeigt, wo die Zeit in PHPUnit-Suites wirklich verloren geht und wie man durch Bootstrap-Optimierung, pcov, schlanke Fixtures und Test-Splitting messbare Gewinne erzielt.

Ein HTML-Coverage-Report ist gut fuer den Ueberblick, aber schlecht zum Arbeiten. PhpStorm zeigt Testabdeckung direkt farbig im Editor-Gutter an, sodass ungedeckte Zeilen sofort dort sichtbar sind, wo gerade programmiert wird.