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.
The file is structured like this:
registry: registry: - product - current_product - current_category - current_entity_key helper: - catalogsearch singleton: - catalog/layer - core/session - customer/session - catalog/session - customer/session - reports/session resource: - catalog/category_indexer_product
As soon as one test uses one of the annotations
@resource, the entries of the YAML file are overwritten. Using both together does not work!
Some not quite obvious singletons that can lead to frustration, are:
customer/session– as soon as you work with product collections, a customer session is instantiated automatically (because of group prices). In this case, it’s the best in my experience to inherit your test from
EcomDev_PHPUnit_Test_Case_Controllerand start the customer session like this:
customer/sessionbelongs on the list of singletons to reset, just like all other session models.
catalog/category_indexer_producty(Resource Singleton) – I stumbled over this just today: If the tests run on a virgin database and the Magento setup scripts are triggered in the same process, this singleton saves the stores before the default store even exists. As soon as the indexer is triggered but cannot find any stores, you’ll see this helpful error message:
Fatal error: Uncaught exception 'Exception' with message 'Notice: Undefined variable: enabledTable in /var/www/app/code/core/Mage/Catalog/Model/Resource/Category/Indexer/Product.php on line 941
That’s why this singleton should always be resetted and the registry fixture that takes care about this should be loaded bevore any EAV fixture