wiki.techinc.nl/tests/phpunit/bootstrap.php

101 lines
3.8 KiB
PHP
Raw Normal View History

<?php
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +00:00
/**
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
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
*
* @file
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +00:00
* @ingroup Testing
*/
use MediaWiki\MainConfigSchema;
require_once __DIR__ . '/bootstrap.common.php';
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +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
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +00:00
$GLOBALS['wgAutoloadClasses'] = [];
$GLOBALS['wgBaseDirectory'] = MW_INSTALL_PATH;
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +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" );
// Extract the defaults into global variables.
// NOTE: this does not apply any dynamic defaults.
foreach ( MainConfigSchema::listDefaultValues( 'wg' ) as $var => $value ) {
$GLOBALS[$var] = $value;
}
TestSetup::requireOnceInGlobalScope( MW_INSTALL_PATH . "/includes/DevelopmentSettings.php" );
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',
[
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
);
$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 );
}
// 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 );
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 ) );
/** @internal For use in ExtensionsTestSuite only */
define( 'MW_PHPUNIT_EXTENSIONS_TEST_PATHS', explode( "\n", $testPathsStr ) );
$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 );
}
$autoload = $extensionProcessor->getExtractedAutoloadInfo( true );
AutoLoader::loadFiles( $autoload['files'] );
AutoLoader::registerClasses( $autoload['classes'] );
AutoLoader::registerNamespaces( $autoload['namespaces'] );
// More faking in lieu of Setup.php
Profiler::init( [] );
TestSetup::maybeCheckComposerLockUpToDate();