
Problem/Motivation
Test for aggregator module are scattered around in other modules. We need to consolidate these tests into the modules directory (core/module/aggregator
) and into the modules namespace.
This way it will be easier to move the current Core module almost as-is to the Contrib realm
Steps to reproduce
Proposed resolution
Move all tests to the aggregator module.
Remaining tasks
Move all tests to aggregator module.
#3265424: Move migrate related aggregator tests to the module in preparation of removal in d10
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#57 | raw_diff_d10-d94-57.txt | 82.22 KB | spokje |
#57 | 3264122-9_4-57.patch | 116.08 KB | spokje |
#57 | interdiff_54-57.txt | 1.49 KB | spokje |
Issue fork drupal-3264122
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:
Comments
Toggle MR activity (91 comments)added 2 commits
Compare with previous version
added 3 commits
Compare with previous version
Comment #3
spokjeadded 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 2 commits
Compare with previous version
added 4 commits
project:9.4.x
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 6 commits
project:9.4.x
Compare with previous version
I'm very unsure what this test is supposed to test or has been testing before, but currently it passes without using Queues and aggregator, which seem to leave only a simple form submit test?
Although it works for this MR, since it doesn't need to use the aggregator module, I think a follow-up issue might be in order to either delete or fix this test?
Unsure why this test ever needed aggregator? It passes without it.
Comment #4
bbralaadded 7 commits
project:9.4.x
Compare with previous version
added 1 commit
Compare with previous version
added 3 commits
project:9.4.x
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 3 commits
project:9.4.x
Compare with previous version
added 12 commits
project:9.4.x
Compare with previous version
Since this test doesn't seem to need the aggregator module, should there be a aggregator counterpart test as this MR currently adds in
core/modules/aggregator/tests/src/Functional/migrate_drupal_ui/d6/IdConflictTest.php
?Since this test doesn't seem to need the aggregator module, should there be a aggregator counterpart test as this MR currently adds in
core/modules/aggregator/tests/src/Functional/migrate_drupal_ui/d6/MultilingualReviewPageTest.php
?Since this test doesn't seem to need the aggregator module, should there be a aggregator counterpart test as this MR currently adds in
core/modules/aggregator/tests/src/Functional/migrate_drupal_ui/d6/NoMultilingualReviewPageTest.php
?Since this test doesn't seem to need the aggregator module, should there be a aggregator counterpart test as this MR currently adds in
core/modules/aggregator/tests/src/Functional/migrate_drupal_ui/d6/NoMultilingualReviewPageTest.php
?Since this test doesn't seem to need the aggregator module, should there be a aggregator counterpart test as this MR currently adds in
core/modules/aggregator/tests/src/Functional/migrate_drupal_ui/d7/MultilingualReviewPageTest.php
?added 3 commits
project:9.4.x
Compare with previous version
Since this test doesn't seem to need the aggregator module, should there be a aggregator counterpart test as this MR currently adds in
core/modules/aggregator/tests/src/Functional/migrate_drupal_ui/d6/NodeClassicTest.php
?Comment #5
quietone CreditAttribution: quietone at PreviousNext commentedI will start looking into all the migration tests. It is a bit tricky because aggregator is used to do some extra checking on the migration state and that will have to move to another module. I hope to make more informed comments as a I make commits,
Comment #6
spokjeThanks @quietone, I've been looking at the non
migrate_drupal_ui
migration related failing tests when I remove the completecore/modules/aggregator
directory on top if the changes here on10.0.x-dev
. but am to scared/ignorant to touch them.They definitely need the touch of a Migration MasterMind.
Also I've left (quite) a few remarks in the MR on the code>migrate_drupal_ui changes that I've made. If you could comment on those as well that would be great.
The test should be checking that there are no Id conflicts with aggregator but it is not. That is a mistake that can be fixed in the aggregator module.
The module is needed in the test so that the aggregator migration state is discovered. However, that state is overridden by the state file in a test module. A comment should have been added to explain that.
A counterpart in aggregator is not needed. Aggregator doesn't create nodes so doesn't impact a node migration from the UI.
The module is needed in the test so that the aggregator migration state is discovered. However, that state is overridden by the state file in a test module. A comment should have been added to explain that.
The module is needed in the test so that the aggregator migration state is discovered. However, that state is overridden by the state file in a test module. A comment should have been added to explain that.
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 2 commits
Compare with previous version
Comment #7
quietone CreditAttribution: quietone at PreviousNext commentedJust updated the functional tests for the aggregator module.
The migrate fixtures are copied to aggregator module so that the aggregator tests are independent of future changes to the fixtures.
A followup could be made in aggregator to add testing of aggregator Id conflicts. This is not tested in core so is a new test. I did check this locally and it works as expected.
added 1 commit
Compare with previous version
Comment #8
quietone CreditAttribution: quietone at PreviousNext commentedStarted on the Kernel tests. This changes the aggregator migration Kernel tests to use the test fixture in aggregator.
There are more Kernel tests to handle.
The size of this MR is increasing and I wonder if we should make it easier to review by breaking up into sensible parts. At least the migration work can be done in a separate issue.
added 1 commit
Compare with previous version
Comment #9
quietone CreditAttribution: quietone at PreviousNext commentedFor some of the tests I put in an @todo for the cases where aggregator can be removed when the module if removed from core. They should has an issue number but don't. Is there an issue for the actual removal?
Assuming what I have done is correct and tests are passing, the task remaining is to figure out what to do for d6_block and d7_block migrations. Perhaps, in a few hours, I can pick this up again.
added 1 commit
Compare with previous version
Comment #10
catch#3264120: Remove aggregator module and our dependency on Laminas Feed is the removal issue.
changed this line in version 26 of the diff
changed this line in version 26 of the diff
changed this line in version 26 of the diff
changed this line in version 26 of the diff
changed this line in version 26 of the diff
added 14 commits
Compare with previous version
Comment #11
quietone CreditAttribution: quietone at PreviousNext commented@catch, thanks, I was going to find look properly for that link today.
On further thought, I think it will help reviewers if the migration work is moved to a separate issue, so I have added a child issue. I've reverted the migrate related changes here.
Comment #12
spokjeAdding above mentioned issue []#3265424 as related (Thanks @quietone for the excellent work done on migrations). Unsure if this should be postponed on that issue.
Pretty sure this should go into
10.0.x-dev
first (See #3263654-28: Move all HAL tests to the module in preparation of removal in D10).Not doing the admin for that currently.
Comment #13
spokjeReverting unplanned status change
Comment #14
quietone CreditAttribution: quietone at PreviousNext commented@Spokje, this doesn't need to be postponed on #3265424: Move migrate related aggregator tests to the module in preparation of removal in d10.
Updating the title to make it clear that this isn't doing the migration tests. And removing the [PP-1] from the title because it has been set to active.
Comment #15
spokjeThanks @quietone.
Upped version to
10.0.x-dev
added 10 commits
project:9.4.x
Compare with previous version
added 4 commits
Compare with previous version
added 2 commits
project:9.4.x
Compare with previous version
added 1 commit
Compare with previous version
added 3 commits
project:9.4.x
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
Comment #17
spokjeMR!1812 ->
9.4.x-dev
MR!1852 ->
10.0.x-dev
Attached a raw diff between the two MRs.
Comment #18
spokjeadded 8 commits
project:10.0.x
Compare with previous version
added 6 commits
project:9.4.x
Compare with previous version
Comment #19
xjmThis seems to contain moving Help Topics as well as tests? Shouldn't that be a separate scope?
added 14 commits
project:9.4.x
Compare with previous version
added 17 commits
project:10.0.x
Compare with previous version
Comment #20
xjmFNW for #19.
BTW, it's preferred to rebase these MRs against HEAD instead of merging HEAD to them. :)
Comment #21
spokje> BTW, it's preferred to rebase these MRs against HEAD instead of merging HEAD to them. :)
Must have missed that somehow in the documentation, could you point me to where I can find that?
Comment #22
ankithashettyThere is a message on the MR page saying
the source branch must be rebased onto the target branch.
added 8 commits
project:10.0.x
Compare with previous version
Comment #23
ankithashettyJust rebased the MR with the latest 10.0.x branch.
Comment #24
spokjeThanks @ankithashetty for pointing me to (at least the GitLab) documentation, unsure if the MR needed a rebase already.
@xjm:
Can we have a section added to the Update Drupal deprecation policy about the correct procedure to deprecating/removing core modules and themes, as marked as a "Remaining task" in the IS of #3135100: [policy and meta] Provide a proper mechanism for deprecating modules and themes?
I've spent (way too much) time on trying to get
quickedit
,hal
andaggregator
deprecated/removed, and, during the last two weeks, only seen all three of them moving "forwards" faster than Michael Jackson doing the moonwalk, meaning that they are on a forward track, but they're actually moving backwards and are only getting postponed on more and more on sub-issue blockers.Since we're obviously doing something (kinda) new here, bumping into unexpected things is to be expected.
Adding extra blockers on it due to (at least me) being unsure about to need for help topics, moving core issues about the modules to the Contrib queue, altering textual references like for example in
core.api.php
etcetera, needing a separate issue or not, would be a shame IMHO.IMHO Looking at the cut-off date of (I actually don't know for sure) when 9.4.0 will be released, it's getting more and more uncertain if we can make it with the modules that started the journey Core => Contrib already.
A clear What-To-Do-Beside-Break-The-Glass-In-Case-Of-Emergency-And-Core-Module/Theme-Deprecation would save everybody a lot of time (again IMHO :)
Comment #25
bbralaI agree with you there @Spokje. Its hard work and understand your frustration in running into blocker after blocker that you could not have foreseen.
Comment #26
spokjeThanks @bbrala.
Personal frustration is temporary, missing the deadline of
9.4.0
is forever (or at least until anotherx.y.0
deadline).I'm fully OK with being frustrated for a tiny bit, but it would be a shame to miss deadlines because of unclear admin on creating sub-issues.
Comment #27
spokjeSorry for the noise, but prevent even more coming in, there's a Slack thread for "Deprecating/Removing Core Modules for Dummies" right here: https://drupal.slack.com/archives/C014CT1CN1M/p1645607618306019.
Since this issue isn't about that guidance, let's discuss it down there for now.
Comment #28
catchfwiw I think it's worth doing that in a separate issue - in this case it's just git mv so it'll be a very easy RTBC and commit, then mean a smaller diff to review here. If it was just one or two tests + help topics and just moving things around, then could probably get away with a single issue though.
added 1 commit
Compare with previous version
added 34 commits
project:10.0.x
Compare with previous version
added 4 commits
project:10.0.x
Compare with previous version
Comment #29
spokjeThanks @quietone for the moving-the-move of the aggregator related help topics to its own issue.
Rebased once again and putting back to Needs Review.
I'm very unsure what this test is supposed to test or has been testing before, but currently it passes without using Queues and aggregator, which seem to leave only a simple form submit test?
Although it works for this MR, since it doesn't need to use the aggregator module, I think a follow-up issue might be in order to either delete or fix this test?
Unsure why this test needed aggregator? It passes without it.
Comment #31
spokjeCopied over my 2 remarks from the
9.4.x
-MR and closed that one, since it was outdated and we need to go into10.0.x-dev
first anyway.This is (Yet Again) a massive MR to review, but most of the changes are Views related, where we "simply" changed the signature of one
function setUp()
which cascades into a snowball-from-hell quite quickly.We did the same for the deprecation/removal of
hal
BTW, so no rocket scientist were harmed (or even used) during the creation of this MR.The actual test-moving-around is quite small, since the migration issue #3265424: Move migrate related aggregator tests to the module in preparation of removal in d10 is doing a lot of the heavy lifting for that.
Comment #32
spokjeUnrelated test-failure is being handled here: #3267124: Temporarily skip failing tests and even appears to pop up in the current HEAD of
10.0.x-dev
at the time of testing: https://www.drupal.org/pift-ci-job/2330048.Keeping this on NR.
Comment #33
quietone CreditAttribution: quietone at PreviousNext commentedadded 4 commits
project:10.0.x
Compare with previous version
Comment #34
daffie CreditAttribution: daffie commentedThe change to modules/views/tests/src/Functional/ViewTestBase.php does not look necessary. Can somebody explain why it is in?
Comment #35
catchJust committed the patches for migration-related tests and help_topics, so this issue should hopefully have a clean run now.
added 6 commits
project:10.0.x
Compare with previous version
added 1 commit
Compare with previous version
added 2 commits
Compare with previous version
Comment #36
spokje@daffie:
This is because of the moving of the view
test_style_opml
to the aggregator module incore/modules/aggregator/tests/modules/aggregator_test_views/test_views/views.view.test_aggregator_style_opml.yml
.Since it's now not in the
test_views
module anymore, it's not automagically past along as a default value to thesetUp()
method. Changing that cascaded in a Whole Lot OfRosieChanges insetUp()
for subclasses ofViewTestBase
.We did something similar for the
hal
module in its MR.Hope that makes any sense?
Comment #37
spokjeRebased MR after relevant MRs/patches were committed (thanks @catch) and tried to answer @daffie's question (Thanks for the review)
added 9 commits
project:10.0.x
Compare with previous version
Can we change the variable name to
$test_views_modules
. The variable is holding an array of modules with test views.Lets create a followup with what to do with this test.
A lot of tests have the change as above. Are all those tests actually using the module
views_test_config
or can that be removed? In this test it can be changed to$test_views_module = []
.Can we change
TRUE
for$import_test_views
.Can we change
TRUE
for$import_test_views
.Comment #38
daffie CreditAttribution: daffie commentedComment #39
spokjeI've actually looked into this a bit more and we don't need an actual valid queue, but rather a valid
\Drupal\Core\Queue\DatabaseQueue
object, which doesn't have to be a valid queue.I've checked and the queue in this change has the same properties as the original
'aggregator_refresh'
queue had.Looking at the MR for
hal
where we did something similar, the variable name used there (and thus currently already in Core) is$modules
, which is also plural.To prevent different variable names for the same thing, I've ran with
$modules
in this MR also.I hope that's OK with you?
Absolutely, nice catch.
Ditto
changed this line in version 14 of the diff
changed this line in version 14 of the diff
changed this line in version 14 of the diff
changed this line in version 14 of the diff
added 9 commits
project:10.0.x
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 1 commit
Compare with previous version
added 5 commits
project:10.0.x
Compare with previous version
added 1 commit
Compare with previous version
Comment #40
spokjeadded 1 commit
Compare with previous version
Comment #42
taran2lThis MR cannot be rebased automatically, so let's wait it to pass and then I'll do it manually.
added 40 commits
project:10.0.x
Compare with previous version
Comment #43
taran2lComment #44
taran2lOK, after rebase run has a single (I believe a random) failure ... keeping the status
The diff is huge, but a large proportion of it is multiple changes like this.
Since we've already split the aggregator removal scope into multiple issues, I think it's fine to handle this in this patch even though it doesn't explicitly mention aggregator.
Was wondering if it was really OK to remove this, until I realised it was doing precisely nothing given the next line.
Comment #45
catchOK I reviewed this line by line.
It's a massive diff. Most of it is changes to views tests (almost all the same change) due to the way test views are handled after the removal of the OPML test view from views into aggregator. I was nearly tempted to ask for that to be moved to a different issue, but we've split the aggregator removal scope up a lot already, and since there's not that many other changes in the patch, I think it's fine here.
There are probably things we can do to further clean-up some of these tests, but that's all out of scope here which is about removing dependencies. So... RTBC for me.
Comment #46
alexpottCommitted 39b12c4 and pushed to 10.0.x. Thanks!
Do we want to try to backport some of the changes here to 9.4.x to make test maintenance easier?
Comment #48
catchI think it would be good to backport the entire patch to 9.4.x if we can, so that the contrib and 9.4.x versions of aggregator are as close as possible.
Comment #49
spokjeI would say an absolute YES! to backporting to
9.4.x-dev
.This to keep:
- Inline with previously deprecated/removed Core modules where we did this (HAL, QuickEdit)
- Make test maintenance easier.
- Make backporting in general easier (remember the SA issue on HAL anybody?)
- Make the Contrib incarnation of aggregator as close as possible to the remaining core one
Would that mean a new MR/patch or does the current one also apply on
9.4.x-dev
?INSTA-EDIT: Too slow...
Comment #50
spokjeIt doesn't,
9.4.x-dev
patch incoming.Comment #51
spokjeComment #53
spokjeComment #54
spokje*sigh* There's always one that escapes...
Comment #55
spokjeComment #56
catchStraight re-roll as far as I can see
This from the raw diff looks like it might need adding to the 9.4.x patch (so it doesn't appear in the diff between the 9.4 and 10.x changes).
Otherwise looks good to me.
Comment #57
spokjeThanks @catch, that one indeed didn't make it through the manual re-add new files check :/
Added in attached patch, leaving it on RTBC.
Comment #58
spokjehe said whilst browser put it back to NR
Comment #60
alexpottCommitted ed58a15 and pushed to 9.4.x. Thanks!
Comment #63
berdirThe ViewTestBase change is really awkward, that causes a breaking change in test modules, I don't really see right now how a test class would be able to support both D10 and D9 with that constructor change. Going to to try and remove the constructor entirely, but it's a bit awkward.
Edit: I might be wrong, I think you can have more extra arguments, just not less? Still a bit awkward, but less of an issue then.
Comment #64
quietone CreditAttribution: quietone at PreviousNext commentedI added the needs followup tag and I don't think it is necessary to add an ID conflict test to aggregator, it is the job of migrate to find ID conflicts not aggregator. There was other discussion about a followup in this discussion in the MR. The reply from @Spokje implies a follow up is not needed. I am removing the tag.