Problem/Motivation
What is TestSetupTrait::$originalProfile for?
It is only ever set by TestBase::prepareEnvironment() before the test is run. This is presumably so that it can be restored after the test is finished. However, this never happens.
It is also used by FunctionalTestSetupTrait to populate some config for the fixture site. Currently ['conf']['simpletest.settings']['parent_profile’] (will change in #3080482: Decouple FunctionalTestSetupTrait from the simpletest module).
This config is then used to manipulate extension discovery in ExtensionDiscovery and ModuleExtensionList.
This complexity seems to only be needed to support the use case of WebTestBase tests when run from the Simpletest UI, in order to restore the original profile to the parent site’s configuration.
If we are removing the simpletest module from core, as in #3057420: [meta] How to deprecate Simpletest with minimal disruption, then we need to remove these unneeded subroutines.
If we’re keeping the simpletest module, then we need to fix the usage of this variable and figure out whether it meets all our use-cases.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 3081501_8.patch | 5.51 KB | mile23 |
| #7 | 3081501_7.patch | 13.74 KB | mile23 |
Comments
Comment #2
mile23I'm filing this for 8.8.x, but it might well be more appropriate and easier to answer in 9.x.
Also, it's postponed on #3080482: Decouple FunctionalTestSetupTrait from the simpletest module
Comment #3
wim leersI also noticed the pointlessness of
$originalProfilewhile working on #2352949: Deprecate using Classy as the default theme for the 'testing' profile!+1 to removing it.
Comment #4
mile23Comment #5
catchComment #6
mile23Related issue trying to iron out why we have the
install_profilesetting/config.Comment #7
mile23This is essentially the patch from #3080482-18: Decouple FunctionalTestSetupTrait from the simpletest module. That's comment #18. And as @alexpott says in #19:
I think this is mostly right in that people think they have two profiles when they're writing the test. The thing is: They really don't. This just makes it less magical and more obvious.
Comment #8
mile23Let's try that again, this time after a rebase... (After #2982680: Add composer-ready project templates to Drupal core was committed, woohoo!)
Comment #9
wim leersI'm inclined to agree with
… but this does seem like it could break some really obscure tests. So tagging for release manager review.
Comment #10
wim leersActually, that was probably premature. A subsystem maintainer is more likely to be able to thoroughly and efficiently assess the impact of this change.
Also, I think this needs a change record.
Sorry, @Mile23!
Comment #11
alexpottAs a subsystem maintainer +1
Also I disagree that we need a CR here as there is nothing for someone to change - $originalProfile is set by the system and not the test developer. If this does cause a test failure then you're probably not testing what you think you're testing. Also note core almost certainly has the most complex set of install profile tests anywhere and this change does not cause us to have to change any tests.
Comment #12
wim leersSee, that's exactly why I wanted a subsystem maintainer to review this — because I don't know enough about this to assess whether it's truly RTBC-worthy or not :) Thanks, @alexpott!
Comment #13
wim leersGiven #11 which addresses my reasons for in-RTBC'ing in #10, I'm now comfortable RTBC'ing this like I did in #9 :)
Comment #14
alexpottCommitted 4e3cc12 and pushed to 8.8.x. Thanks!
<3 This makes me happy. One less way of doing super strange low-level things.
Removed unused use on commit.