#3475056: Make relevance the default sort introduced a script to regenerate fixture re-generation. However, #3485386: Do not hardcode UUIDs in DrupalJsonApi plugin introduced a new way to get the UUIDs of certain taxonomy terms so they wouldn't be hardcoded, and the previous script was based on the old values, so if we try to regenerate them again we get 0 results, because the UUIDs are not the right ones.
php scripts/regenerate-drupalorg-jsonapi-fixture.php
Get the UUIDs dynamically and build the queries with the right ones.
Show commandsStart 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:
changes
Comments
Comment #3
fjgarlin commentedOk, it took longer than expected but I tried to make it as solid as possible. The script regeneration works now much better.
The script has some configuration constants, that would not need changing unless the tests and fixtures change. I made comments were relevant and the script gives output on whether the fixture was saved or not. It also offers suggestions to change some old UUIDs for new ones if needed.
However, there are things that we should change for future tests writing regarding the fixtures.
- It doesn’t make sense to check whether we have 4564 results or 1897 results. We just one results, so we can change things for regex checks instead.
- When checking list of returned modules, the lists should be small rather than having 8-10 modules, as results can change.
- One of the tests checks for the newest modules… this will always change on regeneration.
Right now the tests are falling due to expecting certain list of modules and certain number of results. It also needs rebasing and solving the conflict because of a commit that happened today.
Comment #4
fjgarlin commentedThis is finally ready to be checked. The re-generation is now fully automated, it offers suggestions on what to change in the tests and the tests are a bit less flaky, as we don't check an exact list of modules in certain order (that's already tested on other classes).
I insist that the followup #3489987: Simplify tests for JsonApi plugin should be addressed anyway, as all we should be checking in the JsonApi plugin is that it is able to consume the jsonapi data and produce results. This can be a kernel or even unit test, but I'll let that be decided in the other issue.
As far as this go, I think it's ready.
Comment #5
narendrarRegenerated fixture on local using
php scripts/regenerate-drupalorg-jsonapi-fixture.phpand run all tests inProjectBrowserUiTestJsonApi. All tests are passing after fixture update.Moving this issue to RTBC.
Comment #6
chrisfromredfinPlease just address the one comment. I'd love to understand why the JSON files are numbered. Either change them away from being numbered to something more self-documenting, or document the "why" for numerically-named files in the function's DocBlock / a code comment explaining why they are the way they are.
Comment #7
fjgarlin commentedThat's a good point. I was just keeping what was in there, I don't think there is the need for numbers anymore, especially with the new script that only takes "keys" and "values".
I'll change it.
Comment #8
fjgarlin commentedFeedback addressed.
Comment #9
chrisfromredfinHaven't updated where the fixture files are generated. :)
Comment #10
fjgarlin commentedDone that now. Well spotted. Back to needs review.
Comment #11
chrisfromredfinThere we are!