Seite 9 - PHPUnit

Ohne saubere Fixtures sind Integrationstests fragil: Tests erzeugen Testdaten, die den nächsten Test beeinflussen, Rollbacks schlagen fehl und das Fixture-Skript ist an einem anderen Pfad als erwartet. Das Magento Test Framework bietet ein ausgefeiltes Fixture-System – vorausgesetzt, man versteht die Mechanismen dahinter.

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.

willReturn() deckt den überwiegenden Teil aller Mock-Bedürfnisse ab, einen festen Wert zurückgeben, fertig. Manchmal reicht das aber nicht: Ein Mock muss abhängig vom übergebenen Argument unterschiedlich reagieren, oder sein Verhalten muss sich über mehrere Aufrufe hinweg dynamisch ändern. Genau dafür gibt es willReturnMap und willReturnCallback. Dieser Artikel zeigt, wie beide funktionieren und wo die Grenze liegt, ab der ein Mock eigentlich schon zu viel Logik enthält.

Ein isolierter Observer-Test ruft die Observer-Klasse direkt auf und prueft nie, ob das Event ueberhaupt in events.xml korrekt verdrahtet ist. Ein end-to-end Test ueber den echten Event-Dispatch deckt genau diese Luecke ab.

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.