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.
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.
Column not found: 1054 Unknown column ‘sales_bestsellers_aggregated_yearly.product_type_id’ in ‘field list
You might receive this error message in a fresh Magento 1.9.3 installation with sample data when trying to log into the admin panel. I got it after installing https://github.com/andreaskoch/dockerized-magento and found a few reports online, but no solution.
I don’t know the root cause yet, but to be able to log in again, you can set a different admin startup page:
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.
“Helpers” are often used as convenient collection of functions. They are also a sign of bad design, and I want you to stop writing them. I’ll quote myself
In general, having classes named “Helper”, “Util” or similar just says “I have some functions that I don’t know where to put” and don’t make much sense as a class.
It’s not very object oriented. Not at all to be frank. The idea of object oriented programming is that there are objects that send each others messages. They have an active role in the system and are not just containers for data and code, which would be a very procedural way to see them.
So what would be the role of a helper? A butler maybe, that does not act on its own and will do anything you tell him. But to do that, he needs access to your whole household, your bank account and your car.
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
For years, the test framework EcomDev_PHPUnit is quasi-standard for Magento unit tests. The current version is 0.3.7 and last state of official documentation is version 0.2.0 – since then, much has changed which you have to search yourself in code and GitHub issues. This series shall collect practical usage tips.
Tip #14: Registry Fixtures
As already explained in Tip #1, helpers, singletons and registry values can be reset per test. Finding the problematic singletons etc. often was the most difficult part of writing integration tests with EcomDev, so I started to collect them centralized in one fixtures/registry.yaml file for all tests 1. Better reset one too many than one to little.