May 2015 - schmengler-se.de

27. May 201513. January 2020

My Checklist For Magento Shop Analysis

For me, the first step before starting work on an unknown existing Magento installation, is always a shop analysis. Not only to understand the requirements and processes of the merchant, but also and above all to evaluate the quality and recognize possible problems early on. Unfortunately, many shops are tinkered without any knowledge of conventions and best practices, which leads to:

Suffering performance
Security vulnerabilities
Impossibility to update
Unmaintainable code

Points 1 and 2 directly affect the merchant, point 3 and 4 lead to bugs being accumulated over time, which results in new changes causing bugs in different places, that get harder and harder to solve.

This bug-ridden cycle is often the reason merchants try a new agency or developer to “fix everything”, so it is no coincidence that most shops that land on my desk are in such a degenerated state. The more important it is to analyze first, before any quote for further development and maintenance, to not fall into the same trap as the predecessor and to add clarity on both sides.

Three-Tier Analysis

The analysis has a three-tier design such that after the first tier (1 to 2 hours of effort) there is already a rough estimation of quality and need for action, and after the second tier it is possible to make a quote for cleaning and updating the shop.

EcomDev_PHPUnit Tip #9

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 #9: Checkout Test

3 Years ago I already wrote an article about how to write a checkout integration test. But the practices used there are not longer up to date and some workarounds have become unnecessary. This post shows what’s necessary to write a test that simulates the Magento checkout, using techniques learned in Tip #1.

Since there are some singletons involved, make sure to reset their state:

/*
 * @test
 * @singleton checkout/session
 * @singleton customer/session
 * @singleton checkout/cart
 */

You should visit the cart page once to trigger totals collection. Assuming, the customer id is 1 and she has an active quote (from previously added products in the test or from a quote fixture), you start with:
```
$this->customerSession(1);
$this->dispatch('checkout/cart');
```
Before each new request, you have to reset the checkout session singleton manually within the test, otherwise the quote is not reloaded and you might even lose it completely:
```
Mage::unregister('_singleton/checkout/session');
$this->customerSession(1);
$this->dispatch('checkout/onepage');
```

Sometimes you want to logout a customer with active shopping cart. This needs three steps:

Mage::getSingleton('customer/session')->logout();
Mage::getSingleton('checkout/cart')->unsetData();
$this->guestSession();

7. May 201513. January 2020

EcomDev_PHPUnit Tip #8

Tip #8: “sort_order is ambiguous” Error

Zend_Db_Statement_Exception: SQLSTATE[23000]: Integrity constraint violation: 1052 Column ‘sort_order’ in order clause is ambiguous

If you get this MySQL error in your tests, you probably forgot the attribute set in your EAV fixtures. attribute_set_id should always be set, even for customers and addresses (just use “0” there)

5. May 201513. January 2020

EcomDev_PHPUnit Tip #7

Tip #7: YAML Directory Fallback

YAML files for fixtures, expectations and data providers are expected in the following scheme by default, where in this example Importer.php contains the test case and testImport is the test method:

│   Importer.php
│
├───Importer
│   ├───expectations
│   │       testImport.yaml
│   │
│   ├───fixtures
│   │       testImport.yaml
│   │
│   └───providers
│           testImport.yaml

Here the signature with annotations:

    /**
     * @param string $csv CSV file content
     * @test
     * @loadFixture
     * @loadExpectation
     * @dataProvider dataProvider
     */
    public function testImport($csv)

Instead of the method name the file name of the YAML file can also be stated explicitly, like in this example where another test also uses fixtures/testImport.yaml (how this also works for data providers, see Tip #3).

    /**
     * @param string $csv CSV file content
     * @test
     * @loadFixture testImport
     * @dataProvider dataProvider
     * @expectedException RuntimeException
     */
    public function testFailingImport($csv)

But even the directory structure doesn’t have to be used in this form. If EcomDev_PHPUnit doesn’t find the according file in this place, the following fallback hierarchy is used:

Default: see above
Module: The directories “fixtures”, “expectations” and “providers” are searched directly in the “Test” directory of the module
Global: The directories are searched in any parent directory of the test case up until the Magento root

This way you can use fixtures etc. across multiple test cases. Today I prefer the second variant for module wide definition in most cases, at least for fixtures.

Incidentally, the hierarchy is defined in the EcomDev_PHPUnit config.xml as follows:

<config>
    <phpunit>
        <suite>
            <yaml>
                <model>ecomdev_phpunit/yaml_loader</model>
                <loaders>
                    <default>ecomdev_phpunit/yaml_loader_default</default>
                    <module>ecomdev_phpunit/yaml_loader_module</module>
                    <global>ecomdev_phpunit/yaml_loader_global</global>
                </loaders>
            </yaml>
        </suite>
    </phpunit>
</config>

These loaders are models which inherit from EcomDev_PHPUnit_Model_Yaml_AbstractLoader, so with an own module you theoretically can add own custom loaders to use arbitrary sources for the YAML files.