Introduce an alternative way to define fixtures using PHP8 Attributes#509
Introduce an alternative way to define fixtures using PHP8 Attributes#509bubasuma wants to merge 1 commit intomagento:masterfrom
Conversation
|
I am all for improvements for the testing framework's abilities. One concern which I will voice here in the hope of it being considered. If/and when the new fixtures get introduced can the existing fixture files (like for example these https://github.com/magento/magento2/tree/2.4.4/dev/tests/integration/testsuite/Magento/Sales/_files) please be deprecated rather than getting removed immediately. Reason being it will be quite a few years until php 7.x will no longer be in use in the Magento ecosystem and we are actively using the current fixtures in our testing. While Adobe might be able to move on quickly we as extension developers try to support older versions while they are still popular. |
|
This is a step in the right direction as it makes it much easier to use configurable fixtures |
Problem
Recently, we introduced parameterized fixture for integration and api-functional test that accepts parameters directly from @magentoDataFixture annotation.
We enhanced
@magentoDataFixtureannotation format to support additional information that contains the parameters and the alias of a fixture. And we introduced a new annotation @magentoDataFixtureDataProvider for advanced fixture configuration.However, with the current implementation, fixture parameters have to be passed in JSON format which is hard to read and maintain. PHP 8.0 introduced a new feature (Attributes) that we can utilize to generate fixtures instead of DocBlock annotations which will enable us to use PHP build in syntax and increase the code readability.
Example
Solution
PHP 8.0 introduced a new feature (Attributes) that we can utilize to generate fixtures instead of DocBlock annotations.
Implementation
Create PHP attribute equivalent for all existing DocBlock annotations used in integration and functional tests
@magentoAppIsolation->AppIsolation@magentoDbIsolation->DbIsolation@magentoDataFixtureBeforeTransaction->DataFixtureBeforeTransaction@magentoDataFixture->DataFixture(1)@magentoApiDataFixture->DataFixture(1)@magentoIndexerDimensionMode->IndexerDimensionMode@magentoComponentsDir->ComponentsDir@magentoAppArea->AppArea@magentoCache->Cache@magentoAdminConfigFixture->Config(2)@magentoConfigFixture->Config(2)(1) Both
magentoDataFixtureandmagentoApiDataFixturecan be replaced withDataFixtureattribute. Currently we usemagentoDataFixturein integration tests andmagentoApiDataFixturein functional api tests (WebAPI). Both executes data fixtures except thatmagentoApiDataFixturedoes not trigger db transaction (db isolation) by default (without explicitly enabling db isolation with @magentoDbIsolation) whereasmagentoDataFixturedoes.All it takes to make this work is to replace
\Magento\TestFramework\Annotation\DataFixturewith\Magento\TestFramework\Annotation\ApiDataFixturein WebapiDocBlock and override\Magento\TestFramework\Annotation\AbstractDataFixture::getDbIsolationStatein\Magento\TestFramework\Annotation\ApiDataFixture(ApiDataFixture extends DataFixture which also extends AbstractDataFixture) to return[disabled]instead ofNULLin case the db isolation is not explicitly defined. This will prevent the transaction from auto starting in \Magento\TestFramework\Annotation\DataFixture::startTestTransactionRequest unless explicitly enabled with@magentoDbIsolation.(2) Both
magentoAdminConfigFixtureandmagentoConfigFixturecan be replaced withConfigattribute.Example:
Pros
Cons
Thumbs up 👍 if you like this proposal