Follows-up I58ff3c193190d78a. Small step toward not run-time reading
the global (and using Config here is non-trivial/unsafe).
Change-Id: Ic527e493baabe700c50f75fadaa5b51615a5e597
This change cleans up when and how we register autoloader info for
extensions.
This bumps CACHE_VERSION to 8, to avoid issues in case this patch gets
reverted: the new code doesn't copy the map of class files into
$info['globals']['AutoloadClasses']. If old code was to read a new cache
entry, autoloading would fail.
BREAKING CHANGE: The following methods have been removed from
ExtensionRegistry without deprecation and without replacement.
They had been introduced in 1.35 for use in the testing framework,
and were not in use by any known extension:
- exportAutoloadClassesAndNamespaces
- exportTestAutoloadClassesAndNamespaces
NOTE: breaks the hack that SocialProfile has in place for T243861.
Bug: T240535
Change-Id: I6e1ceac034c443d9475f1adc1babecddd6af6d05
DefaultSettings.php has been replaced by MainConfigSchema.
Loading DefaultSettings.php is deprecated.
Code that needs to have access to configuration defaults should use the
ConfigSchema service object.
Bug: T300129
Change-Id: I7b2c0ca95a78990be1cdb9dd9ace92f6dcf1af15
The global variable $IP has been replaced by the MW_INSTALL_PATH
constant. Clarify the continued use of $IP on Setup.php.
Change-Id: I157abfd9049fb8382da53005a084ab86f47e8d8a
TestSetup seems a nice place for this function. This way, it can also be
reused in the other boostrap file whilst we migrate the entrypoint.
Also, replace the check in MediaWikiIntegrationTestCase with another
constant; this also makes it easier to understand when exactly that code
should run.
Bug: T90875
Change-Id: I7858d982378ab4b6f11c4e9bf955d83d1acbc85d
Application logic should use the BaseDirectory config variable.
Framework code should use MW_INSTALL_PATH to locate files should.
NOTE: Update https://www.mediawiki.org/wiki/Manual:$IP
Bug: T300301
Depends-On: I7142af16d692f26e90673b058029f572c1ea3991
Change-Id: Ib4caa80bb7007c4c7960a2fd370cf5da7d9ba344
wfDetectLocalSettingsFile already defines MW_CONFIG_FILE, defining
it again in bootstrap.php triggers a warning.
Bug: T301503
Change-Id: I0f2892dd803e4d7be0e3e8c8bca26b1251bc6f14
This allows a file other than LocalSettings.php to be used as the primary
settings file by setting the MW_CONFIG_FILE environment variable.
This also allows the primary settings file to use YAML or JSON format.
Using static configuration files should be the default in the future.
However, YAML files in the document root could easily be exposed to the
public. Better not to encourage that, and require them to be enabled
explicitly and loaded from a different place.
Bug: T294750
Change-Id: I7747f83481cb05a6d05f819be652259951183819
In order to allow configuration default to come from JsonSchema,
and dynamic defaults need to be initialized in Setup.php.
This movesd the initialialization of $wgExtensionDirectory and $wgStyleDirectory
to Setup.php
Bug: T294788
Change-Id: I11f5723aa299caa210cf6a1f5b7436f191b1ffc2
When invoking `composer phpunit:unit` without any configuration, we lack
custom logging or developer enhancements such as $wgDevelopmentWarnings.
Inject `includes/DevelopmentSettings.php` in the PHPUnit bootstrap.
The $wgMWLoggerDefaultSpi is set to LegacyLogger which requires four
global variables:
- `$wgDebugLogFile`
- `$wgDebugLogGroups`
- `$wgDBerrorLog`
- `$wgDBerrorLogTZ`
Allow `$wgDebugLogFile` and `$wgDebugLogGroups` globals to be passed to
unit tests. `$wgDBerrorLog` and `$wgDBerrorLogTZ` are not, since I don't
think that applies to unit tests.
This change does not affect integration tests run via phpunit.php, where
developers may include DevelopmentSettings.php from LocalSettings.php in
a custom order before/after their own changes, or not at all.
Bug: T291227
Change-Id: I792ca0be3456f83b86fb4ebddae4117bf387be3a
Right now, for autoloading, it depends on a complex logic of
DirectoryIterator and a hard-coded set of extension.json names.
This is not useful and also doesn't pick up Wikibase extension.json
files because they are extension-repo.json and extension-client.json
which in turn causes all sorts of warnings
This patch fixes that
Bug: T243124
Change-Id: Iaf47a6f485f4ba2769b4e384278c8121366dd9a5
applyInitialConfig() was introduced to merge config setup between
phpunit.php and parserTests.php, but this test entry point was missed.
Change-Id: I94c8a31056127f2e3d6a0ddf47d18b9bae114abb
This introduces two new keys to the extension schema, analogous to
the existing autoloader keys: TestAutoloadNamespaces and
TestAutoloadClasses.
The classes and namespaces defined by these keys are only loaded by
the registry when ExtensionRegistry::setLoadTestClassesAndNamespaces
is called. The phpunit wrapper does this in PHPUnitMaintClass::setup.
The unit test bootstrap file calls
ExtensionRegistry::exportTestAutoloadClassesAndNamespaces instead,
similar to how it loads the regular classes and namespaces.
Bug: T196090
Change-Id: I88cf69663362fd599c20649b1df641907a02678d
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
Also use wgExtensionDirectory and wgStyleDirectory in bootstrap.php, and add
clarifying comment about why ExtensionRegistry->readFromQueue is not used.
Follows-Up: I237a9f82e4d1b05cf2f08b3e4bb7ffcd8d47111c
Bug: T226911
Change-Id: I9c8e70006600c6eebbdc46dc7483a4481859ea16
Prior to this patch, one could not run this command from within an extension
directory: `../../vendor/bin/phpunit -c ../../phpunit.xml.dist tests/phpunit`,
because our code in bootstrap.php loaded "LocalSettings.php" instead of
$IP/LocalSettings.php.
Note that making this change does not result in loading LocalSettings.php when
running unit tests.
Bug: T87781
Change-Id: Iee8440f11a2bb255567646289a1986d636c12765
For now only extensions with skin/extension.json which follow PSR-4 are
supported.
DefaultSettings is loaded in bootstrap to work around errors when unit tests are
run followed by integration tests (e.g. `vendor/bin/phpunit`)
Usage:
- composer phpunit:unit will run all unit tests in core and any tests in
`{extensions/skins}/tests/phpunit/unit` which also extend
MediaWikiUnitTestCase, and which have an extension.json file
- Pass a specific directory to only run unit tests for a particular extension,
e.g. `composer phpunit:unit -- extensions/GrowthExperiments`
Bug: T226911
Change-Id: I237a9f82e4d1b05cf2f08b3e4bb7ffcd8d47111c
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
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
This will be called right before the shutdown procedure begins,
so that all variables and classes still exist, and the hooks
can actually work.
See task for details.
Bug: T219673
Change-Id: Id6b2b4b7958b78822a0868720f7b0ba46d7b4951
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
- Remove check for version, that version is already enforced in phpunit.php,
so there is not point showing a warning for it is useless
- Remove call to MessageCache::destroyInstance(), there is no need for it,
since $wgMessageCacheType is set in phpunit.php before running Setup.php
- Remove includes of bootstrap.php in LanguageSrTest.php and LanguageUzTest.php
Change-Id: I4b2db6b3e6f001175e1a407c5add2972aade5e60
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
As Setup.php assigns variables based on the cache config, bootstrap.php was late on reseting them, as some objects were already created.
So we could end up with a SqlBagOStuff created there, which when later accessed (such as trying to invalidate the cache for a user) would
-as any non-sqlite SqlBagOStuff- open a new db connection. Which is precisely what we shall not be done when dealing with temporary tables
(and would indeed fail miserably due to not finding unittest_objectcache table).
In summary, reenabling temporary tables disabled in r79411.
* MessageCache::singleton() calls wfGetMessageCacheStorage() directly instead of using $messageMemc, just in case this would be called before that variable is set
* Per TimStarling: also removed deprecated methods in MessageCache class: addMessages() and related, [get|set|enable|disable]Transform(), loadAllMessages(), loadMessageFile() and some others. Same for the legacyData stuff in LocalisationCache that was only used by MessageCache::addMessages() and related.
* Converted remaining extensions
Don't setup/destroy for databaseless tests.
Make needsDB() return based on the DocComment.
Delayed db init until the test is run, so that it isn't set for excluded tests (the exclusion is done after all the classes are instantiated).
lack of fuzz testing and other parser test options, and the DB creation is still a little flaky.
A MediaWikiPHPUnitCommand class had to be created to allow for custom CLI parameters.
-Add a working PHPUnit test that instantiates a new DB, adds set data, and deleted when done.
-Add listTables() to the Database classes (only MySql and SQLite use it, and only MySQL is tested)
