Seite 5 - PHPUnit

Ein Test, der manchmal besteht und manchmal nicht, ist schlimmer als gar kein Test. Er untergräbt das Vertrauen in die gesamte Testsuite, erzwingt manuelle Re-Runs und versteckt echte Regressionen hinter rauschen. Flaky Tests entstehen aus spezifischen Ursachen – und alle lassen sich dauerhaft beheben.

Wer PHPUnit-Ergebnisse nur als Terminalausgabe betrachtet, verschenkt den größten Teil des Mehrwerts automatisierter Tests. JUnit XML, HTML-Coverage, Teamcity-Output und strukturierte Testdauer-Reports machen Test-Ergebnisse für CI-Systeme, Teams und Monitoring auswertbar – über einen einzelnen Build-Lauf hinaus.

PHPUnit 11 ist kein inkrementelles Update – es entfernt Docblock-Annotations zugunsten nativer PHP-Attribute, verschärft die Coverage-Konfiguration, ändert das Mock-System grundlegend und setzt PHP 8.1 als Mindestanforderung. Wer migriert, muss mehr als nur die Versionsnummer in composer.json ändern.

Test-Driven Development wird oft entweder verteufelt oder als Allheilmittel angepriesen. Die Realität in PHP-Projekten ist differenzierter: TDD funktioniert hervorragend für bestimmte Problemklassen und erzeugt unnötigen Overhead für andere. Dieser Beitrag zeigt, wo der Unterschied liegt – mit Code, nicht mit Theorie.

SearchCriteria-Abfragen, Collection-Filter und EAV-Attribute sind die drei häufigsten Datenzugriffsmuster in Magento – und gleichzeitig die drei häufigsten Stellen, an denen Tests entweder fehlen oder falsch strukturiert sind. Dieser Artikel zeigt, welcher Testtyp für welchen Zugriff geeignet ist und wie man jeden korrekt absichert.

Duplikate Testdaten in jedem setUp, magische Arrays in DataProvidern und hartcodierte IDs verstreut über Hunderte von Testklassen – das sind die typischen Zeichen einer Testsuite ohne klare Datenorganisation. Builder-Pattern, Fixture-Klassen und Factory-Methoden bringen Ordnung ohne Overengineering.

Magento-Unit-Tests ohne Bootstrap laufen in Sekunden statt in Minuten. Aber nicht jede Magento-Klasse lässt sich sinnvoll ohne Framework-Initialisierung testen. ViewModels, reine Service Classes, Plugins auf einfache Daten-Transformationen und Preisberechnungslogik sind ideal. Block-Rendering, Layout-Verarbeitung und Observer-Ketten hingegen brauchen den Bootstrap – und das ist kein Versagen des Tests.

PHPUnit findet Laufzeitfehler – aber nur, wenn die entsprechenden Tests existieren. PHPStan und Psalm finden Typfehler statisch, bevor der Code je ausgeführt wird. Erst die Kombination beider Ansätze schließt die Lücken, die jedes Tool allein offen lässt. Dieser Artikel zeigt, wie man PHPStan, Psalm und PHPUnit als durchgehende Qualitätskette in PHP-Projekten integriert.