2010-12-14 16:26:35 +00:00
|
|
|
<?php
|
2019-06-26 02:33:14 +00:00
|
|
|
|
2010-12-14 16:26:35 +00:00
|
|
|
/**
|
2019-06-26 02:33:14 +00:00
|
|
|
* PHPUnit bootstrap file.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
2010-12-14 16:26:35 +00:00
|
|
|
*
|
|
|
|
|
* @file
|
2019-06-26 02:33:14 +00:00
|
|
|
* @ingroup Testing
|
|
|
|
|
*/
|
|
|
|
|
|
2022-02-21 16:28:35 +00:00
|
|
|
use MediaWiki\MainConfigSchema;
|
|
|
|
|
|
2023-07-08 13:27:52 +00:00
|
|
|
require_once __DIR__ . '/bootstrap.common.php';
|
2019-06-26 02:33:14 +00:00
|
|
|
|
2022-04-24 12:36:10 +00:00
|
|
|
/** @internal Should only be used in MediaWikiIntegrationTestCase::initializeForStandardPhpunitEntrypointIfNeeded() */
|
|
|
|
|
define( 'MW_PHPUNIT_UNIT', true );
|
|
|
|
|
|
phpunit: Repair GLOBALS reset in MediaWikiUnitTestCase
This code didn't work because the $GLOBALS array is exposed by reference.
Once this reference was broken by unset(), the rest just manipulated a
local array that happens to be called "GLOBALS". It must not be unset or
re-assigned. It can only be changed in-place.
Before this, the execution of a MediaWikiUnitTestCase test stored a
copy of GLOBALS in unitGlobals, then lost the GLOBALS pointer and
created a new variable called "GLOBALS". As such, the tearDown() function
didn't do what it meant to do, either – which then results in odd
failures like T230023
Rewrite it as follows:
* In setup, store the current GLOBALS keys and values, then reduce
GLOBALS to only the whitelisted keys and values.
* In teardown, restore the original state.
* As optimisation, do this from setUpBeforeClass as well, so that
there are relatively few globals to reset between tests.
(Thanks @Simetrical!)
The following tests were previously passing by accident under
MediaWikiUnitTestCase but actually did depend on global config.
* MainSlotRoleHandlerTest (…, ContentHandler, $wgContentHandlers)
* SlotRecordTest (…, ContentHandler, $wgContentHandlers)
* WikiReferenceTest (wfParseUrl, $wgUrlProtocols)
* DifferenceEngineSlotDiffRendererTest (DifferenceEngine, wfDebug, …)
* SlotDiffRendererTest (…, ContentHandler, $wgContentHandlers)
* FileBackendDBRepoWrapperTest (wfWikiID, "Backend domain ID not provided")
* JpegMetadataExtractorTest (…, wfDebug, …, LoggerFactory, …)
* ParserFactoryTest (…, wfDebug, …, LoggerFactory, InvalidArgumentException)
* MediaWikiPageNameNormalizerTest (…, wfDebug, …, LoggerFactory, …)
* SiteExporterTest (SiteImporter, wfLogWarning, …)
* SiteImporterTest (Site::newForType, $wgSiteTypes)
* ZipDirectoryReaderTest (…, wfDebug, …, LoggerFactory, …)
Bug: T230023
Change-Id: Ic22075bb5e81b7c2c4c1b8647547aa55306a10a7
2019-08-07 13:40:55 +00:00
|
|
|
// Faking in lieu of Setup.php
|
2019-06-26 02:33:14 +00:00
|
|
|
$GLOBALS['wgAutoloadClasses'] = [];
|
2022-02-21 16:28:35 +00:00
|
|
|
$GLOBALS['wgBaseDirectory'] = MW_INSTALL_PATH;
|
2019-06-26 02:33:14 +00:00
|
|
|
|
2023-07-13 00:01:29 +00:00
|
|
|
TestSetup::requireOnceInGlobalScope( MW_INSTALL_PATH . "/includes/AutoLoader.php" );
|
|
|
|
|
TestSetup::requireOnceInGlobalScope( MW_INSTALL_PATH . "/tests/common/TestsAutoLoader.php" );
|
|
|
|
|
TestSetup::requireOnceInGlobalScope( MW_INSTALL_PATH . "/includes/Defines.php" );
|
|
|
|
|
TestSetup::requireOnceInGlobalScope( MW_INSTALL_PATH . "/includes/GlobalFunctions.php" );
|
2019-07-01 19:33:54 +00:00
|
|
|
|
2022-02-21 16:28:35 +00:00
|
|
|
// Extract the defaults into global variables.
|
|
|
|
|
// NOTE: this does not apply any dynamic defaults.
|
|
|
|
|
foreach ( MainConfigSchema::listDefaultValues( 'wg' ) as $var => $value ) {
|
|
|
|
|
$GLOBALS[$var] = $value;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 00:01:29 +00:00
|
|
|
TestSetup::requireOnceInGlobalScope( MW_INSTALL_PATH . "/includes/DevelopmentSettings.php" );
|
2022-02-21 16:28:35 +00:00
|
|
|
|
2020-04-21 05:47:54 +00:00
|
|
|
TestSetup::applyInitialConfig();
|
|
|
|
|
|
phpunit: Determine what extensions to load in unit tests via config
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
2023-07-13 00:57:20 +00:00
|
|
|
// Shell out to another script that will give us a list of loaded extensions and skins. We need to do that in another
|
|
|
|
|
// process, not in this one, because loading setting files may have non-trivial side effects that could be hard
|
|
|
|
|
// to undo. This sucks, but there doesn't seem to be a way to get a list of extensions and skins without loading
|
|
|
|
|
// all of MediaWiki, which we don't want to do for unit tests.
|
|
|
|
|
// phpcs:ignore MediaWiki.Usage.ForbiddenFunctions.proc_open
|
|
|
|
|
$process = proc_open(
|
|
|
|
|
__DIR__ . '/getPHPUnitExtensionsAndSkins.php',
|
|
|
|
|
[
|
2023-09-27 13:22:44 +00:00
|
|
|
0 => [ 'pipe', 'r' ],
|
phpunit: Determine what extensions to load in unit tests via config
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
2023-07-13 00:57:20 +00:00
|
|
|
1 => [ 'pipe', 'w' ],
|
|
|
|
|
2 => [ 'pipe', 'w' ]
|
|
|
|
|
],
|
|
|
|
|
$pipes
|
|
|
|
|
);
|
|
|
|
|
|
2023-07-13 20:13:18 +00:00
|
|
|
$extensionData = stream_get_contents( $pipes[1] );
|
phpunit: Determine what extensions to load in unit tests via config
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
2023-07-13 00:57:20 +00:00
|
|
|
fclose( $pipes[1] );
|
|
|
|
|
$cmdErr = stream_get_contents( $pipes[2] );
|
|
|
|
|
fclose( $pipes[2] );
|
|
|
|
|
$exitCode = proc_close( $process );
|
|
|
|
|
if ( $exitCode !== 0 ) {
|
|
|
|
|
echo "Cannot load list of extensions and skins. Output:\n$cmdErr\n";
|
|
|
|
|
exit( 1 );
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 20:13:18 +00:00
|
|
|
// For simplicity, getPHPUnitExtensionsAndSkins uses `\n\nTESTPATHS\n\n` to separate the lists of JSON files and
|
|
|
|
|
// additional test paths, so split the output into the individual lists.
|
|
|
|
|
[ $pathsToJsonFilesStr, $testPathsStr ] = explode( "\n\nTESTPATHS\n\n", $extensionData );
|
phpunit: Determine what extensions to load in unit tests via config
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
2023-07-13 00:57:20 +00:00
|
|
|
$pathsToJsonFiles = explode( "\n", $pathsToJsonFilesStr );
|
2022-01-28 19:17:51 +00:00
|
|
|
|
phpunit: Determine what extensions to load in unit tests via config
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
2023-07-13 00:57:20 +00:00
|
|
|
/** @internal For use in ExtensionsUnitTestSuite and SkinsUnitTestSuite only */
|
|
|
|
|
define( 'MW_PHPUNIT_EXTENSIONS_PATHS', array_map( 'dirname', $pathsToJsonFiles ) );
|
2023-07-13 20:13:18 +00:00
|
|
|
/** @internal For use in ExtensionsTestSuite only */
|
|
|
|
|
define( 'MW_PHPUNIT_EXTENSIONS_TEST_PATHS', explode( "\n", $testPathsStr ) );
|
2022-03-24 14:18:07 +00:00
|
|
|
|
|
|
|
|
$extensionProcessor = new ExtensionProcessor();
|
|
|
|
|
|
phpunit: Determine what extensions to load in unit tests via config
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
2023-07-13 00:57:20 +00:00
|
|
|
foreach ( $pathsToJsonFiles as $filePath ) {
|
|
|
|
|
$extensionProcessor->extractInfoFromFile( $filePath );
|
2019-07-01 19:33:54 +00:00
|
|
|
}
|
2022-03-24 14:18:07 +00:00
|
|
|
|
|
|
|
|
$autoload = $extensionProcessor->getExtractedAutoloadInfo( true );
|
|
|
|
|
AutoLoader::loadFiles( $autoload['files'] );
|
|
|
|
|
AutoLoader::registerClasses( $autoload['classes'] );
|
|
|
|
|
AutoLoader::registerNamespaces( $autoload['namespaces'] );
|
2022-06-28 01:39:08 +00:00
|
|
|
|
|
|
|
|
// More faking in lieu of Setup.php
|
|
|
|
|
Profiler::init( [] );
|
2023-02-24 09:54:49 +00:00
|
|
|
|
2023-07-10 21:50:22 +00:00
|
|
|
TestSetup::maybeCheckComposerLockUpToDate();
|