EntityViewsDataTest tests the behaviour of the EntityViewsData class.
However, because it's a unit test, the test is very close to the implementation. All the services the class expects have to be mocked very precisely.
This means that issues that need to fix problems in EntityViewsData which would require a change to either which services are injected, or what is called on those services, are stuck, because these changes to EntityViewsData have knock-on effects on the test. It's a very complicated class, and a very big test (~1200 lines!), with LOTS of mocking, and so it's a pretty horrendous task. Also, having to change both the SUT and the test at the same time is not a good thing -- because it pretty much invalidates the tests, as they can't tell you whether you've broken anything.
Some of the issues stuck by this include:
- #2930736: EntityViewsData assumes BaseFieldDefinitions where it should use FieldDefinitionInterface
- #2898635: bundleFieldDefinitions() are not added in EntityViewsData
- #2981047: Allow adding computed bundle fields in Views
I propose that we rewrite EntityViewsDataTest as a kernel test. This would mean we remove all the mocking. We define entity types, and let the entity system pass that to EntityViewsData, and test the output. We then have a test that isn't tied to the implementation details of the class.
Issue fork drupal-3116481
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3116481-convert-entityviewsdatatest-to-kernel-test
changes, plain diff MR !980
Comments
Comment #2
joachim commentedAs this is going to be a lot of work, would be good to get a green light from a subsystem maintainer before starting work.
Comment #5
dawehnerI just had a look at the class and the test. Much like the class has a bit of logic, I believe the complexity is really in the integration level.
For this a kernel test makes definitely way more sense.
In doubt this might require setting up additional test entity types, but I think the clarity and more important the resilience would be certainly improved, when the test is a kernel test
Comment #7
joachim commentedComment #8
joachim commentedI'm making good progress on this.
- much less mocking to do, so much less code!
- the unit test actually uses entity type definitions from the entity_test module, which I find a bit weird... it's actually pretty simple to put the definitions in the test
- found a bug in the test!
Comment #10
joachim commentedDone!
Comment #12
daffie commentedThe test is changed to a kernel test. Great!
Now it needs a bit of love to get it committed.
Comment #13
joachim commentedThanks for your help with making the tests pass!
> Why add this todo? Can we not just do it? It looks simple enough
> Can we change this to an assertTrue().
> Can we change this to an assertArrayNotHasKey().
Because this is a test conversion, I think that the new test class needs to be as similar as possible to the unit test class we're removing, to help reviewers understand the changes and see clearly that the new test is still covering all the same things.
Changing the type of assertions will add a lot of noise to the diff and possibly make git diff stop seeing it as as a file rename, which will then make reviewing even harder.
I agree with the suggested changes to the assertions, but I think they should be done in a follow-up.
Comment #14
daffie commentedAll right lets do the cleanup in a followup. For that I have created #3225692: Cleanup the EntityViewsDataTest.
All code changes look good to me.
The patch fixes the problem from the IS.
For me it is RTBC.
Comment #15
joachim commentedRemoving the tag, as that was addressed in #5.
Comment #16
owenbush commentedAdding #2981047: Allow adding computed bundle fields in Views as blocked in the issue description
Comment #17
alexpottCommitted and pushed 47c2f348cf to 9.3.x and eabee5c4c8 to 9.2.x. Thanks!
Backported to 9.2.x as this is only a test.