Field Types should be integration tested on 2 different levels:
- Their integration with the Persistence SPI
- Their integration with the Public API
For both test environments, infrastructure is already in place, so that you can easily implement the required tests for your custom Field Type
This type of integration test ensures, that a Field Type stores its data properly on basis of different Persistence SPI implementations.
By now, only the Legacy Storage implementation exists.
The integration tests with the Persistence SPI can be found in
eZ\Publish\SPI\Tests\FieldType. In order to implement a test for your custom Field Type, you need to extend the common base class
eZ\Publish\SPI\Tests\FieldType\BaseIntegrationTest and implement its abstract methods. As a reference the
UserIntegrationTest can deal.
The gateway configuration for basic field types are located in eZ/Publish/Core/settings/storage_engines/legacy/external_storage_gateways.yml.
On a second level, the interaction between an implementation of the Public API (aka the Business Layer) and the Field Type is tested. Again, there is a common base class as the infrastructural basis for such tests, which resides in
Note that the In-Memory stubs for the Public API integration test suite, do not perform actual Field Type calls, but mainly emulate the behavior of a Field Type for simplicity reasons.
If your Field Type needs to convert data between
getFieldData(), you need to implement a
eZ\Publish\API\Repository\Tests\Stubs\PseudoExternalStorage in addition, which performs this task. Running the tests against the Business Layer implementation of the Public API is not affected by this.