In a future with a single bootstrap and config, we won't be able to run
hooks as early as in ExtensionTestSuite::suite. On top of that, if the
config file does not fully load the MW config (as is the case with
bootstrap.php), it won't even be possible to run hooks at all.
So move the relevant code from ExtensionsTestSuite to
getPHPUnitExtensionsAndSkins, collect the output in bootstrap.php and
pass it to ExtensionsTestSuite.
This hack wouldn't be necessary if the UnitTestList hook didn't exist,
but fortunately there are plans to get rid of it (T298509).
Keep the old code in place when entering from an entry point that
doesn't load bootstrap.php (i.e., phpunit.php and composer
phpunit:entrypoint).
Bug: T227900
Change-Id: Idf72db24dbd66bb66baf51564a7504d2bc035e8c
When running unit tests, the bootstrap would previously load all
extensions and skins in the filesystem. This was OK for an initial
implementation, but is not acceptable if we want to eventually do that
for all PHPUnit entry points (once we'll have a single config and
bootstrap). Instead, it's desirable to only load the extensions
specified in LocalSettings.php. The problem is that it's pretty much
impossible to load LocalSettings.php without also loading the rest of
MediaWiki, with all the side effects this might have.
This patch introduces a helper script that loads all the config, then
prints what extensions and skins were loaded. The bootstrap file runs
this script via proc_open and then reads the list of extensions to
load. Because the script is run in a separate process, any side effects
only affect the spawned process, not the one where PHPUnit is running.
Currently, there doesn't seem to be a better way to obtain the list of
extensions loaded in LocalSettings.php without all the other side
effects. YAML settings
(https://www.mediawiki.org/wiki/Manual:YAML_settings_file_format) would
probably help, but that's very far from becoming the only supported
config format (if it will ever be).
Also add two TestSuite implementations to replace the '*' wildcard in the
extensions:unit and skins:unit suites. These use the same list of loaded
extensions to determine where to look for tests.
And last but not least: my most sincere apologies to you if the hack
you're seeing here has ruined your day. If you think a better approach
exists, please tell me and I'll be so relieved!
Bug: T227900
Change-Id: Ib578644b8a4c0b64dca607afb9eb8204ca7fc660