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.
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.
Architekturregeln, die nur in Dokumenten existieren, werden gebrochen. Mit PHPUnit, PHP-Arch und der Reflection API lassen sich Schichtengrenzen, Modulabhängigkeiten und Designregeln als ausführbare Tests formulieren – die sofort anschlagen, wenn eine Klasse die falsche Schicht aufruft oder ein Modul eine verbotene Abhängigkeit einführt.
Wer Tests ohne klare Muster schreibt, bekommt eine Testsuite, die langsam, brüchig und schwer zu verstehen ist. DataProvider, aussagekräftige Assertions, isolierte Mocks und eine sinnvolle Coverage-Strategie trennen Tests, die bei Refactoring sofort anschlagen, von grünen Tests, die trotz Bugs grün bleiben.
Wer Magento-Module ohne Integrationstests entwickelt, merkt Regressionen erst im Staging oder in der Produktion. Das Magento Test Framework bietet eine vollständige Umgebung mit echter Datenbankisolation, automatischer Fixture-Verwaltung und dem gesamten Magento-DI-Container – vorausgesetzt, man richtet es korrekt ein.
Wer Magento-Code ohne Tests schreibt, merkt bei jedem Refactoring, wie fragil die Abhängigkeiten wirklich sind. PHPUnit-Tests für Repositories, Service-Contracts und ViewModels decken die Logik der wichtigsten Schichten ab – ohne den vollständigen Magento-Bootstrap zu benötigen
Wer ein gewachsenes PHP-Projekt auf PHPUnit 10 oder 11 hebt, begegnet einer Flut von Deprecation-Notices, geänderten Assertion-Signaturen und entfernten Interfaces. Dieser Artikel zeigt einen strukturierten Weg durch die Migration – ohne die laufende Testsuite zu gefährden und ohne jede Testklasse auf einmal anfassen zu müssen.
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.
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.