- Issue created by @scott_euser
- 🇦🇺Australia acbramley
IMO one of the best ways to solve this would be to stop using yaml files and use the entity API instead to create views in the tests themselves.
This is obviously tricky because views entities don't have an API so it'll be a lot of ArrayPI type things, BUT it will help with an issue I think we're probably running into over years of core dev: No one is really sure what each test view is, what it was created for, and what it should be used for (without going through git). This is resulting in many test views being created or abused in a way just to make testing easier.
I.e - I guarantee many test views are just copy pasted with some small thing changed (add a filter, change a plugin, etc) without actually thinking about if all the things in the view are required for that new test (I know, because I've done exactly this before).
If instead the test itself documented what it needed (in the form of creating the view in the test) then it would be much clearer what bits are actually needed for that particular test.
- 🇬🇧United Kingdom catch
#2 crossed my mind, maybe in the process of doing this with arrayPIs, we might be able to come up with some API methods that would be useful as well. It's something we could do test by test, wouldn't need to be all in one go.
Adding 📌 Rework database update tests so we don't have to ship database dumps in git Active as a related issue, it's only vaguely related but the difficulty of maintaining text fixtures is very similar.
- 🇬🇧United Kingdom scott_euser
Was trying to see if there is a way to add something into ViewTestData::createTestViews() to essentially:
- Replicate the import & resave via Views UI
- Assert that the config in test file matches the config after resave
Got stuck on (1) of course... maybe need to sleep on it a bit. Would welcome any tips/pointers in case anyone has bright ideas to help explore that direction. Maybe its going to be too heavily requiring mimicking form/form state that happens via UI, in which case perhaps not feasible...
Idea being, if we could have a check that config is as expected, we could catch any new additions that cause config to become outated.
