[meta] Decide how to manage test view configuration so it remains up to date

Created on 8 July 2024, 2 months ago
Updated 14 July 2024, about 2 months ago

Problem/Motivation

In πŸ› Views handler loading should respect configuration Active we noticed that the test Views configuration throughout Drupal Core is often getting outdated. While this could be manually fixed and potentially flagged by config validation, ideally we would have an automated mechanism to keep these test views up to date. See for example https://www.drupal.org/project/drupal/issues/3458099#comment-15672296 πŸ› Views handler loading should respect configuration Active

Steps to reproduce

Look at core/modules/rest/tests/modules/rest_test_views/test_views/views.view.test_serializer_display_field.yml for example

  1. Import the yml into a default install
  2. Resave
  3. Export the yml

Many changes are missing

Proposed resolution

TBD

Remaining tasks

Decide on a good way to handle this

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

🌱 Plan
Status

Active

Version

11.0 πŸ”₯

Component
ViewsΒ  β†’

Last updated about 11 hours ago

Created by

πŸ‡¬πŸ‡§United Kingdom scott_euser

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • 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.

  • πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand
Production build 0.71.5 2024