MageTestFest – Eine einzigartige Konferenz und einmalige Gelegenheit

Wenn Du dich für Software Testing und/oder Magento-Entwicklung interessierst, kommt das für interessanteste Event des Jahres näher: MageTestFest in Amerfoort (NL)!

  • 15. Nov: Workshop PHPUnit (Sebastian Bergmann)
  • 16. Nov: Workshop DDD (Mathias Verraes)
  • 17. Nov: Konferenz-Tag (Agenda)
  • 18. Nov: Magento Contribution Day (Hackathon)

Continue reading “MageTestFest – Eine einzigartige Konferenz und einmalige Gelegenheit”

Die Woche auf StackExchange #40/2016

Nachdem der letzte “Wochen auf StackExchange” Post recht lang geworden ist, komme ich zurück auf den wöchentlichen Zeitplan:

Magento 2 Antworten

Offene Fragen

Domain-Logik in Magento-Anpassungen isolieren

Ich habe in letzter Zeit viel dafür plädiert, Geschäftslogik vom Framework (im Speziellen Magento) zu entkoppeln.

Das hat mehrere Vorteile

  • Von testgetriebener Entwicklung (TDD) profitieren, ohne einen Haufen Core Klassen mocken zu müssen.
  • Mögliche Wiederverwendung in verschiedenen Anwendungen (z.B. auch Magento 1 und Magento 2)
  • Separate “bounded contexts” helfen dabei, Teile der Domain isoliert und ohne Ablenkung zu betrachten.

Sogar in chirurgischen Modifikationen, mit denen wir es oft in Magento-Projekten zu tun haben, ist es den Aufwand wert, die eigentliche Logik zu identifizieren und sie von den Magento-Klassen zu extrahieren.

Vollständiger Beitrag auf integer-net.com (Englisch)

Die Woche auf StackExchange #36/2016

Hier sind wieder einige Posts auf Magento StackExchange der letzten Woche, die ich gerne festhalten möchte:

Magento 2

Magento 1

Die Woche auf StackExchange #35/2016

Ich bin etwas spät dran aber ich war in letzter Zeit recht akiv auf Magento StackExchange, also hier sind die besten Posts von letzter Woche!

Magento 1 Antworten

PHPUnit

Neue Magento 2 Fragen

Magento 2 Integration Tests: @magentoConfigFixture

Ich konnte keine gute Dokumentation zur @magentoConfigFixture Annotation in Magento 2 Integrationstests finden, also halte ich hier mal meine Zusammenfassung fest, nachdem ich den Core Code inspiziert habe (Magento 2.1.0, Magento\TestFramework\Annotation\ConfigFixture)

Wie man @magentoConfigFixture nutzt

Standardwert 42 für Konfigurationspfad x/y/z:

/**
 * @magentoConfigFixture default/x/y/z 42
 */

Store-spezifischer Wert 42 für Konfigurationspfad x/y/z im Store mit Code store1

/**
 * @magentoConfigFixture store1_store x/y/z 42
 */

Store-spezifischer Wert 42 für Konfigurationspfad x/y/z in aktuellem Store (also Standard-Store)

/**
 * @magentoConfigFixture current_store x/y/z 42
 */

Das sind alle möglichen Formate. Der erste Parameter muss mit _store enden oder weggelassen werden. Wenn er weggelassen wird, muss der Pfad mit default/ beginnen, sonst wird er ignoriert.

Implikationen

  • Konfigurationswerte können nicht auf Website-Ebene gesetzt werden
  • Man sollte nicht “current” als echten Store Code verwenden, sonst kann für diesen Store keine Konfigurations-Fixture genutzt werden