Problem/Motivation
The list of modules in MigrateUpgradeTestBase can't be over ridden which is inconvenient/annoying when extending this class in contrib. Tests extending this class will have modules enabled that they may not need or want.
The modules listed are those needed for both the d6 and d7 tests, and it is somewhat convenient to have a shared list in one place. However, the modules to install is dependent on what is enabled in the source database and really should be in the respective d6 and d7 tests.
/**
* Modules to enable.
*
* @var array
*/
public static $modules = [
'language',
'content_translation',
'migrate_drupal_ui',
'telephone',
'aggregator',
'book',
'forum',
'statistics',
'migration_provider_test',
];
Proposed resolution
Remove $modules from MigrateUpgradeTestBase
Move the module list to the d6 and d7 tests.
Remaining tasks
Review
User interface changes
N/A
API changes
N/A
Data model changes
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2916199-2.patch | 2.38 KB | quietone |
Comments
Comment #2
quietone commentedComment #3
heddnAssigning to myself to review this week.
Comment #4
heddnWe've also got Drupal\migrate_drupal_ui\Tests\MigrateUpgradeTestBase. Should it also have the modules moved into the d6/d7 implementation classes? Ah, no. Because it is deprecated. So, looks good to me.
Comment #6
quietone commentedTests are passing, back to RTBC.
Comment #8
Anonymous (not verified) commentedRevert status after random fail.
Comment #9
gábor hojtsyHm, this was explicitly only file module before. Why are we enabling all the things now?
Comment #10
heddnre #9: it wasn't just file. It was file, plus all the things in MigrateUpgradeTest. Which is the entire point for this issue. In commerce migrate, we don't want to enable all the things when we extend from MigrateUpgradeTest. We prefer to see that pushed down into the concrete classes. Yes that means more duplication, but it gives the abstract class more utility.
Comment #11
gábor hojtsySo that is because test cases special case this property, see FunctionalTestSetupTrait::installModulesFromClassProperty(). Thanks @phenaproxima for the digging. Thanks!
Comment #13
heddnComment #14
heddn