Tag: Unit Tests

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)

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:

1. Default: see above
2. Module: The directories “fixtures”, “expectations” and “providers” are searched directly in the “Test” directory of the module
3. 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.

Tip #5: Secure Area

Problem: test cases extending EcomDev_PhpUnit_Test_Case_Controller with customer fixture fail with Cannot complete this operation from non-admin area because Magento is in area=frontend mode during tearDown and does not allow deletion of customers. The same problem occurs when you try to delete customers in a test outside of an adminhtml context.

The customer model checks if the isSecureArea flag is set in the Magento registry, so to solve the problem, we set this flag in the test. There are two possible ways to do it:

1.) If you create and delete customers within the test:

/*
 * @test
 * @registry isSecureArea
 */
public function testThatNeedsToDeleteCustomers()
{
    Mage::register('isSecureArea', true);
    // ...
}

(note the @registry annotation which will reset the flag afterwards, see Tip #1)

2.) If you use a customer fixture:

protected function setUp()
{
    Mage::register('isSecureArea', true);
    parent::setUp();
}
protected function tearDown()
{
    parent::tearDown();
    Mage::unregister('isSecureArea');
}

or if you use class wide fixtures:

    public static function setUpBeforeClass()
    {
        Mage::register('isSecureArea', true);
    }
    public static function tearDownAfterClass()
    {
        Mage::unregister('isSecureArea');
    }

Tip #4: Named Parameters

The advantage of YAML files for configuration is supposed to be easy readability. But if a data provider looks like this, there’s not so much readability left:

-
  - 7
  - 1
  -
    5: 7
    6: 9
-
  - 7
  - 1
  -
    5: 8
    6: 10

Technically the same, but way more maintainable:

Bundle_X_A1_B2:
  product_id: 7
  qty: 1
  bundle_selections_by_option:
    5: 7
    6: 9
Bundle_X_A2_B2:
  product_id: 7
  qty: 1
  bundle_selections_by_option:
    5: 8
    6: 10

You can at least guess, that this one is about adding bundle products to the cart, and if you know it, the test data is easy to understand, without having to look at the source code.

Another positive effect is, that for failed tests PHPUnit doesn’t show messages like TestCase::test() with data set #1 anymore, but for example TestCase::test() with data set "Bundle_X_A1_B2"

Tip #3 Shared Data Providers

Did you ever wonder, why you can specify the file name for expectations and fixtures, but for data providers you seem to be limited to the default “test name dot yaml”? The simple reason is, @dataProvider is a native feature of PHPUnit and its parameter actually must be a method name.

So @dataProvider dataProvider means, the method EcomDev_PHPUnit_Test_Case::dataProvider() is used as data provider:

    /**
     * Implements default data provider functionality,
     * returns array data loaded from Yaml file with the same name as test method
     *
     * @param string $testName
     * @return array
     */
    public function dataProvider($testName)
    {
        return TestUtil::dataProvider(get_called_class(), $testName);
    }

But EcomDev_PHPUnit also has a way to specify the file name for the data provider explicitly, thus allows shared providers:

/**
 * @dataProvider dataProvider
 * @dataProviderFile customFileName.yaml
 */
public function testSomething($something)

Tip #2: Expectation Keys

This is a short one: expected('works %s sprintf', 'like').

Which expectations should be loaded, usually depends on input data, so if your expectation file looks like this:

- product-1-qty-10:
  - answer: 42
- product-2-qty-10:
  - answer: 42

you can load it in the test like this:

/**
 * @test
 * @loadExpectation
 * @loadFixture
 * @dataProvider dataProvider
 */
public function testSomething($productId, $qty)
{
  $expectedAnswer = $this->expected('product-%s-qty-%s', $productId, $qty);
}