What to mock in a Magento 2 unit test

You write unit tests for a Magento 2 module and need to mock a core class, like the store model. This class has a few dependencies which have more dependencies and it’s getting complicated to mock. Although PHPUnit 5.4 has a createMock() method that automatically stubs methods and let them return new stubs if they have a return type.

Or: you mock a service contract like getList() in the product repository, which takes a search criteria instance as parameter, which must be returned by a search criteria factory. Then it returns a product search result, which has a getItems() method, which returns a array of products. So you end up mocking countless dependendencies for a single method call

Do these situations sound familiar? It does not need to be like that, though! Let me show you a sane way to deal with Magento dependencies.

Continue reading “What to mock in a Magento 2 unit test”

Learn Refactoring to Framework Independent Code

I’m proud to annouce that I will present the Nomad Mage session of January 2017. Nomad Mage is the Magento offspring of Nomad PHP and describes itself as:

Nomad Mage® is a virtual user group for Magento developers who understand that they need to keep learning to grow professionally. We meet online monthly to hear some of the best speakers in the community share what they’ve learned.

My topic: “Keep Magento Out of Your Magento Extensions – Refactoring to Framework Independent Code”

To port an existing Magento 1 extension to Magento 2, it can be helpful to first extract the business logic into a reusable library. This also makes for more testable and future-proof code. But how can it be done?

On Nomad Mage I’m going to walk through real examples to show you how such a refactoring can be approached. Although we will focus on refactoring existing Magento 1 extensions, the patterns you will learn are also useful for new extensions, Magento 1 or Magento 2.

Continue reading “Learn Refactoring to Framework Independent Code”

PDF Generation in Magento 2

magento-pdf-layout

The Magento core methods to generate PDF files are rather unflexible. An alternative are tools that convert HTML to PDF.

In our current Magento 2 project, which we (integer_net) develop together with Stämpfli AG, there is a requirement to dynamically create a PDF catalog based on selected products, which has almost the same layout as the product lists in the shop. So, generating this PDF based on HTML suggested itself.

In this article I present our solution, which integrates wkhtmltopdf with the Magento layout. At the end you will find a link to the base module on Github.

Continue reading “PDF Generation in Magento 2”

The week on StackExchange #40/2016

Since the last “Weeks on StackExchange” post got quite long, I’ll get back to the weekly schedule:

Hot Magento 2 answers

Open questions

The weeks on StackExchange #37-39/2016

Here we go again, a summary of interesting posts from the last weeks:

Magento 2 CLI

Magento 2 Extension Development

Magento 2 Translation

Magento Product Import

Magento 1 Best Practices

Magento 1 Tipps

PHPUnit

The week on StackExchange #36/2016

And again some new posts from Magento StackExchange that I’d like to highlight:

Magento 2

Magento 1

The week on StackExchange #35/2016

I’m a bit late but I was quite active on the Magento StackExchange recently, so here are the best posts from last week!

Magento 1 answers

PHPUnit

New Magento 2 questions

Magento 2 Integration Tests: @magentoConfigFixture

I did not find a good documentation on how to use the @magentoConfigFixture annotation for configuration fixtures in Magento 2 integration tests, so here is my summary after inspecting the core code (Magento 2.1.0, Magento\TestFramework\Annotation\ConfigFixture)

How to use @magentoConfigFixture

Set default value 42 for configuration path x/y/z:

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

Set store specific value 42 for configuration path x/y/z in store with code store1

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

Set store specific value 42 for configuration path x/y/z in current store (i.e. default store)

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

These are all possible formats. The first parameter must end with _store or be ommitted. And if it is omitted, the path must start with default/, otherwise it is ignored.

Implications

  • You cannot set configuration values on website level
  • Do not use “current” as a real store code, otherwise you cannot use config fixtures for that store

The weeks on StackExchange #33-34 / 2016

Short and sweet: StackExchange posts of the last two weeks.

Magento 1

Magento 2

The weeks on StackExchange #30-32 / 2016

I was active on Magento StackExchange again, here are a few interesting questions and answers from the last three weeks:

Magento 1

Magento 2

Magento Architecture

Good question for understanding “MVC” in Magento: Why does Magento need blocks?. There was a similar question once here: Where’s The V in Magento’s MVC? And is there better name?