Magento 2 · Tests

Unit Tests in Magento 2
schnell und effektiv ohne Bootstrap

Unit Tests in Magento 2 wirken auf viele Teams schwerfällig, weil sie zu nah am Framework oder zu weit weg vom echten Mehrwert gebaut werden. Gute Tests sind dagegen klein, schnell und genau dort platziert, wo eigene Logik wirklich Risiko erzeugt.

17 Min. Lesezeit PHPUnit Magento 2.4.8

Inhaltsverzeichnis

1. 1. Was ein guter Magento 2 Unit Test ist
2. 2. Warum Unit Tests ohne Bootstrap schneller sind
3. 3. Eigene Logik testbar schneiden
4. 4. Mocking mit Maß statt Mocking als Selbstzweck
5. 5. Wo Unit Tests in Magento wirklich lohnen
6. 6. Typische Fehler
7. 7. Unit Tests vs. Integrationstests
8. 8. Magento 2 Unterstützung
9. 9. Zusammenfassung
10. 10. FAQ

1. Was ein guter Magento 2 Unit Test ist

Ein guter Unit Tests Magento 2 Ansatz prüft eigene Logik isoliert und schnell. Das klingt banal, wird aber in der Praxis oft verfehlt. Entweder werden reine Getter, Framework-Konfiguration oder triviale Delegationen

Wer Magento nur über den Server-Load beobachtet, sieht Symptome statt Ursachen. New Relic macht einzelne Transaktionen sichtbar, von der Checkout-Anfrage bis zum externen Zahlungsdienst, und liefert damit die Datenbasis, um Performance-Probleme gezielt statt zufällig zu beheben.

EXTEND

DI

Deep Dive · Magento 2 Erweiterbarkeit

Preferences vs. Plugins:
Wann welche Erweiterungsstrategie?

Wie Interceptoren intern funktionieren, warum Preferences meist die falsche Wahl sind, und die genauen Regeln für Before, After und Around Plugins.

15 min Lesezeit

Magento 2.4.8 · PHP 8.4

Magento Extension Points

Inhalt

1. 1. Zwei Wege, Magento zu erweitern
2. 2. Preferences: Klasse ersetzen via di.xml
3. 3. Warum Preferences problematisch sind
4. 4. Plugins (Interceptoren): Das Interceptor Pattern
5. 5. Before-Plugin: Argumente modifizieren
6. 6. After-Plugin: Rückgabewert modifizieren
7. 7. Around-Plugin: Vollständige Kontrolle (und Risiken)
8. 8. Plugin-Sortierung und Konflikte
9. 9. Plugin-Grenzen: Was Plugins nicht können
10. 10. Entscheidungsmatrix: Preference vs. Plugin vs. Observer

Eine der häufigsten Fragen in Magento-Code-Reviews: "Soll ich eine Preference oder ein Plugin verwenden?" Die Antwort ist fast immer Plugin — aber warum, und mit welchem Typ? Dieser

Magento 2 · Debugging

Xdebug + PHPStorm
der optimale Debug-Workflow

Ein gutes Debug-Setup spart in Magento 2 keine Minuten, sondern oft ganze Tage. Wer Xdebug und PHPStorm sauber für Browser, CLI und Docker aufsetzt, versteht Fehlerpfade schneller und verliert deutlich weniger Zeit an falsche Annahmen.

20 Min. Lesezeit Xdebug Magento 2.4.8

Inhaltsverzeichnis

1. 1. Warum Xdebug PHPStorm Magento 2 mehr als nur ein Setup-Thema ist
2. 2. Xdebug in Docker und Mark-Shust-Umgebungen sauber aktivieren
3. 3. PHPStorm richtig konfigurieren
4. 4. Browser-Requests, Cookies und Breakpoints zuverlässig treffen
5. 5. CLI-Debugging für Setup, Cron und Indexer
6. 6. Ein effizienter Debug-Workflow für Magento 2
7. 7. Typische Fehlerquellen
8. 8. var_dump vs. Xdebug vs. Logs
9. 9. Magento 2 Unterstützung
10. 10. Zusammenfassung und FAQ

1. Warum Xdebug PHPStorm Magento 2 mehr als nur ein Setup-Thema ist

Xdebug PHPStorm Magento 2 wirkt auf den ersten Blick wie ein rein technisches Einrichtungsdetail.

Kundengruppen sind in Magento 2 der zentrale Mechanismus, um Preise und Sichtbarkeit gezielt nach Kundensegment zu steuern: von Großhandelspreisen über verborgene B2B-Kataloge bis zu individuellen Staffelpreisen pro Gruppe. Wer Catalog Price Rules, Tier Pricing, Sichtbarkeits-Plugins und Shared Catalog richtig kombiniert, kann komplexe B2B- und B2C-Preislogik ohne Custom-Checkout-Hacks abbilden, muss dabei aber Reindex-Zyklen, Scoping-Fehler und die Sonderrolle der Gruppe NOT LOGGED IN im Griff behalten.

Composable Commerce löst den monolithischen Shop durch austauschbare, über APIs verbundene Services ab. Magento kann in diesem Modell als reine Commerce-Engine agieren, während Suche, Content und Frontend als eigenständige Bausteine daneben leben. Wer das Prinzip versteht, vermeidet die typischen Fallstricke bei Latenz, Konsistenz und Betriebskomplexität.

Die eingebauten Page Builder Content Types decken Text, Bild und Banner ab, reichen für individuelle Anforderungen aber selten aus. Wer einen eigenen Page Builder Content Type mit Master Format, Formular-Konfiguration und Renderer sauber aufsetzt, gibt Redakteuren ein wiederverwendbares Werkzeug an die Hand, statt für jede Anfrage eine neue Sonderlösung zu bauen.

Transaktionale E-Mails entscheiden darüber, ob Kunden einer Bestellbestätigung, einer Versandmeldung oder einem Zugangslink vertrauen, und in Magento 2 hängt ihre Zuverlässigkeit von einer sauberen Registrierung über email_templates.xml, korrekt genutzten {{var}}- und {{trans}}-Direktiven sowie einer nachvollziehbaren Store-spezifischen Auflösung der E-Mail-Templates ab. Wer eigene Variablen per Plugin injiziert, Header und Footer über Layout-XML pro Store View steuert und lokal mit MailHog testet, baut robuste E-Mail-Templates statt fragiler Einzelfall-Lösungen.

Ein generisches Code-Review übersieht die Fallen, die speziell in Magento zu Produktionsproblemen führen: falsch eingesetzte Preferences, gebrochene public APIs, InstallScripts statt Schema. Eine Magento-spezifische Code-Review-Checkliste macht diese Risiken systematisch sichtbar, bevor sie gemergt werden.

Wenn Vertrieb und Marketing im CRM andere Kundendaten sehen als der Kundenservice in Magento, kostet das Vertrauen und Umsatz. Eine durchdachte CRM-Synchronisation mit klarer Strategie für Batch, Realtime und Event-Verarbeitung sorgt dafür, dass Konten, Adressen und Segmente in beiden Systemen zuverlässig übereinstimmen.