Closed (fixed)
Project:
Drupal core
Version:
8.8.x-dev
Component:
system.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 May 2018 at 11:51 UTC
Updated:
13 Jun 2019 at 13:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jmikii commentedComment #3
jmikii commentedComment #4
jmikii commentedComment #6
amateescu commentedCleaning up tags.
Comment #7
jofitzRe-rolled (because the patch from #3 no longer applies) and corrected the use statements.
Comment #8
jofitzComment #10
huascarmc commentedPick this up at Drupal Camp scotland.
Comment #12
heddnComment #14
heddnSo, we might be outside of my experience with tests. But a functional test that installs a test module that has dependencies on test code in system.module is probably not class loaded. Right? I'm not sure how to fix that. However, I did find a couple issues with the deprecation notices. Fixed here.
Comment #15
heddnIgnore patch in 14. The interdiff was correct. The patch had some noise in it.
Comment #18
mile23The problem here is that both
entity_test.installandentity_test_update.installboth runDbUpdatesTrait::includeUpdates()when they are *included.* That means not inside any hook or anything, just when the file is loaded.Since
Drupal\system\Testsnamespace is always autoloaded at runtime, this wasn't a problem. But since we're doing a better job of isolating test infrastructure from runtime, it's now technical debt.This trait was added in #2542748: Automatic entity updates can fail when there is existing content, leaving the site's schema in an unpredictable state which also fixes a critical. The usage in
entity_test.installwas added then. #2860654: Field storage CRUD operations must use the last installed entity type and field storage definitions adds the usage inentity_test_update.install.DbUpdatesTraitis only used by 4 tests, and two of them don't actually use the trait's methods.So here's what I did:
DbUpdatesTraitfrom tests that don't actually need it.DbUpdatesTraitfrom the two install files. This is a bit of an experiment... Let's see if it represents a regression against #2542748: Automatic entity updates can fail when there is existing content, leaving the site's schema in an unpredictable stateComment #20
mile23Added needs CR update because a) The namespace is wrong in the CR and b) this might be another API change which needs another change record. And if it's not an API change, we still need to document it.
OK, so here's the problem:
An install file running in the fixture of a functional test doesn't autoload the PHPUnit functional test namespaces for a module that isn't enabled.
The system module is not enabled for the two failing tests from #18:
Drupal\Tests\system\Functional\Entity\Update\UpdateApiEntityDefinitionUpdateTestandDrupal\Tests\system\Functional\Update\EntityUpdateToPublishableTestThis means that
Drupal\Tests\system\Functional\Update\DbUpdateTraitcan't be autoloaded during install time, and we shouldn't manually require_once for a trait.Therefore we either add the system module as a dependency of entity_test and entity_test_update (results in fail), or we split out the behavior of
DbUpdatesTrait::includeUpdatesinto a namespace that *is* autoloaded.This patch does the latter, creating
Drupal\system\Tests\Update\GranularUpdateTestTrait, which sort of un-deprecates part of the trait we previously deprecated.Another option is to just unwrap the behavior of
includeUpdates()into the install files themselves, but then you violate DRY, and you also end up making copypasta typos, like I did when I tried it.Comment #22
alexpottThis doesn't need to be trait - it could be final class with a private constructor. It's never properly being used as a trait other than in deprecated code. And in the non deprecated code it can't be used so there's no point it being a trait.
Also in some ways it is a shame to have this in system/src/Tests because it means this code is autoloadable during the regualr Drupal runtime whereas it should only be used by test modules. However we've not really got a better location atm so I guess that is okay.
The foreach is more complex that the two calls before which probably should be preferred because they make you have to think less.
Yay! Like it.
Comment #23
mile23There aren't any more simpletest-based tests in core, according to http://simpletest-countdown.org/
In that spirit, here's the simplest possible patch.
Comment #25
lendudeJust one minor tweak I think.
Comment #26
lendudeNow without the cruft....
Comment #28
lendudeOk so that still leaves #20 to deal with. To stay with the 'minimal possible patch' (which I like), lets forget DRY for weird includes in .install files in test-only code. So that would leave us with something like this....
Comment #29
mile23It's weird that this passes, since this trait is also in used within entity_test_update.install. 'entity_test_update' appears all over the tests, like for instance
Drupal\KernelTests\Core\Entity\EntitySchemaTest. That one should fail based on deprecations if we remove the message from the listener.I think it passes because kernel tests don't install the modules, so the install file is never loaded. Perhaps?
Here's a functional test that installs it:
Drupal\Tests\system\Functional\Update\EntityUpdateAddRevisionTranslationAffectedTestIt ran and passed, because it has
@group legacy. Frownyface. But no wonder:Technical debt with interest.
@group legacywas added in order to get update tests passing, since they call deprecated code. https://www.drupal.org/node/2985785 The unfortunate side-effect being that the test runner won't tell us which code is using deprecated update-related code. This could be fixed by adding the specific deprecation messages at some point in the heirarchy, but I'm not sure that's possible. Anyway, that's out of scope here.I'd say +1 on unwrapping the
DbUpdatesTrait::includeUpdates()into the install files and then finding other uses and unwrapping it there. That way those entity test modules work with either BTB or WTB so we have BC for the unfortunate soul still using simpletest out there somewhere.Comment #30
lendude@Mile23 nice finds!
Updated entity_test_update.install, I don't find any further use of this Trait anywhere.
Reran EntityUpdateAddRevisionTranslationAffectedTest without @legacy and it came back green without the Drupal\system\Tests\Update\DbUpdatesTrait deprecation message (but with all the others still there obviously)
Comment #31
berdirLooks good but \Drupal\Tests\system\Functional\Update\DbUpdatesTrait::includeUpdates doesn't have any usages now, so I'd suggest we deprecate that method as well because it is not possible to use it?
Comment #32
lendudeIt's not possible to use it statically inside an install file, but you could use it if you just
usethe trait in a class and then self:: it, right? Not saying that is likely that anybody uses it that way, but they could....Mostly, if the reasoning is that it can't be used anyway, why bother deprecating it, just toss it.
Comment #33
alexpott+1 from me.
Comment #34
lendudeNice find @Berdir, thanks for the feedback @alexpott.
Tossed.
Updated the CR for this, to indicate that
\Drupal\system\Tests\Update\DbUpdatesTrait::includeUpdateshas no replacement.Comment #35
berdir> It's not possible to use it statically inside an install file, but you could use it if you just use the trait in a class and then self:: it, right? Not saying that is likely that anybody uses it that way, but they could....
Yes, but it is about including update functions, they can not live anywhere else other than in .install, soo..
Comment #36
alexpottCommitted ba5cf8e and pushed to 8.8.x. Thanks!
Fixed up coding standards on commit.