Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In preparation for #1732730: [meta] Implement the new entity field API for all field types it would be useful to have per field-type tests which we then can replicate to all field types that are ported. So let's do some tests for text.module, i.e. create all possible field types, make sure the properties get property intantiated, the right data defintiions are returned and all field values can be read and updated.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1793446.patch | 5.21 KB | fmizzell |
Comments
Comment #1
fmizzell CreditAttribution: fmizzell commentedYesterday I started looking at the latest branch of the property api, so I could start working on this issue, but since this is my first time writing tests, I figure I would share what I was planning on doing before I get to deep into something unusable.
Create a test entity type and bundle to which to attach the test fields. I noticed that the field_test module has a test implementation of an entity type, but it does not use the EntityNG class (I believe this is necessary to get all of the functionality from the property api integration). I was also wondering if it would be good for this "test entity" to be a module in itself so other test could use it instead of creating their own (like field_test does).[Edit: found the entity_test module and where all the core tests are]After creating the entity type and bundle, write the tests:So this is what I am planning on doing:
@fago please let me know if this is in line with what you would do, or if I am on the wrong path.
Also I was trying to find other tests related to the property api without luck, could someone point me in the right direction? Thanks.[Edit: Found the tests]Comment #2
fagoyeah, this sounds good. Also, check the general Entity Field API tests and see what they are testing.
I think we should test:
Ideally, some of this code could even be written generic, so that for a new field type we'd just subclass the test and add some specific code that's required like custom setup logic or tests for certain custom stuff like whether a lazy-loaded enttiy object reflects updates to the id-value.
Comment #3
fmizzell CreditAttribution: fmizzell commentedHere is my first pass at the tests. I know that there is a lot of repetitive code, but I figured I would get some feedback on the methodology before cleaning up.
Also, I was not sure on how to test that the right interfaces are being implemented. Won't things break if the right interfaces are not used to integrate with the system?
Comment #4
fagoWe have something like that already now :)