A number of tests have hardcoded expections that pass only in WMF CI
where Quibble has LocalSettings.php with $wgScript and $wgArticlePath
set a certain way.
We could fix these by adding setMwGlobals() in their tests, as we
often do, but these are so often forgotten that I'd rather we just
add them to TestSetup.php so that it is simply impossible to write a
test that that passes locally for you (if you have the same config)
but not for someone else.
There is a larger project in there somewhere about expanding this
slowly such that we basically only pluck DB-settings and extension
enablement from LocalSettings and otherwise run the tests with the
default settings in PHPUnit. Pretty much by definition, any (other)
setting you have in LocalSettings is irrelevant because it either:
1. has no effect on the test (majority, harmless either way),
2. has a custom default via TestSetup.php (which has precedence over
LocalSettings.php),
3. is relevant to the code being tested and the test case correctly
calls setMwGlobals() to ensure a consistent value during test.
4. is relevant to the tested code but has no override, thus only
passes if you happen to have the "right" value set for it
(undesirable).
Case 4 is already categorically impossible for the most common config
settings that influence random code because we give them a value
in TestSetup.php. This patch expands that to include $wgScript
and $wgArticlePath. Perhaps in the future we can think about a way
to do this automatically by either re-applying MainConfigSchema
(sans db settings) or by only selectively applying LocalSettings.php
in the first place.
This patch follows-up I072ddf89562fe, which added a test case in
WikitextContentHandlerIntegrationTest.php that assumed "/index.php"
as the value of $wgScript. This passes in WMF CI since Quibble uses
that value, but the tests failed in most local development installs
since those tend to use "/w" instead.
Rather than one-off fixing that one test with overrideConfigValues(),
switch to a more general fixture, since the precise values don't
matter for this test.
Bug: T349087
Bug: T277470
Change-Id: If4304b7ca4a838bd892d4516a0b5c6dfbc30986e
According to the dictionary, "per" (or more conventionally "as per")
means "according to". Refer OED "per" sense II.3.a. For example:
"No value was passed, so return null, as per default".
In this sentence, we are not specifying the default, we are referring
to the default. This correct usage of "per default" was used nowhere
in MediaWiki core as far as I can see.
Instead we have "per default" being used to mean "by default", that is,
giving the value to use when no explicit value was specified.
In OED, the phrase "by default" is blessed with its own section just
for computing usage:
"P.1.e. Computing. As an option or setting adopted automatically by a
computer program whenever an alternative is not specified by the user
or programmer. Cf. sense I.7a."
There are highly similar pre-computing usages of the same phrase,
whereas the phrase "per default" is not mentioned.
As a matter of style, I think "per default" should not be used even
when it is strictly correct, since the common incorrect usage makes it
ambiguous and misleading.
Change-Id: Ibcccc65ead864d082677b472b34ff32ff41c60ae
This was added a few weeks ago in change b8f8bcc63f (I49123a5021)
to fix various PHPUnit tests (e.g. CentralAuth, T341731) that failed
due to $wgWikimediaJenkinsCI no longer being set during Setup.php
(and thus the `onRegistration` callbacks in extensions).
This in turn was caused by change d2a30096f (I95a80c44f8d88) which
changed the way tests load LocalSettings.php (no longer in the global
scope), which is why Quibble's LocalSettings.php file, which sets
$wgWikimediaJenkinsCI wasn't taking effect as global variable.
Due to this and other shortcomings with $wgWikimediaJenkinsCI, Quibble
introduced the MW_QUIBBLE_CI env variable. That has the benefit of
always being available, even 1) without relying on a file being in
the global scope, 2) before Setup.php or LocalSettings apply, and
3) in contexts where these will never apply, such as "pure" phpunit
tests that run via `composer phpunit:unit` which don't load
LocalSettings.php at all (which helps address T331621).
This core patch depends on patches that fix current usage in
Wikimedia Gerrit hosted extensions.
Bug: T90875
Depends-On: I996f673add2e8d6e07e20154a90f23eb858ced6b
Depends-On: I0a7470277cdd6939fe3e6e3df92f4d812d320b9c
Depends-On: I25acee1e6e88ca745435cbfa0b398041f04c94d6
Depends-On: I576946230022e9d3518e2ace9ea6f8f1211fcdbe
Change-Id: Ia4df6350f849ca278efef98678850e8c5562f338
* Switch out raw Exceptions, mostly for InvalidArgumentExceptions.
* Fake exceptions triggered to give Monolog a backtrace are for
some reason "traditionally" RuntimeExceptions, instead, so we
continue to use that pattern in remaining locations.
* Just entirely give up on PostgresResultWrapper's resource vs. object mess.
* Drop now-unneeded false positive hits.
Change-Id: Id183ab60994cd9c6dc80401d4ce4de0ddf2b3da0
Set $wgUsePigLatin in TestSetup.php. People tend to conflate
TestSetup with DevelopmentSettings. Really tests are meant to pass just
with TestSetup even though DevelopmentSettings is used in CI.
Change-Id: I1ccc84aad417350d28ca9e4f102a0c85d73c58d4
INSERT IGNORE when inserting NULL into a non-nullable field will succeed
with a warning on MySQL but fail on PostgreSQL. In any case, it's
probably harmful and unintended. But to check the error code of MySQL
warnings, you need to query the server with SHOW WARNINGS, so there is a
performance cost.
So, add a configuration variable which, when enabled, checks warnings
after INSERT to see if there were any null type constraint errors. Set
it to true in DevelopmentSettings.php and TestSetup.php.
Change-Id: I5e47e2d3cc7e0f804036e11b512b1e3b76804432
This was introduced but never really used outside of core[1]. The only
place that used it in core was MainStash setting which under the hood
will use CACHE_DB (SqlBagOStuff).
This patch removes the "db-replicated" key in $wgObjectCaches without
deprecation because it was never really used in the first place and
had a replacement already when it got released, see: T352481.
[1] https://codesearch.wmcloud.org/search/?q=ReplicatedBagOStuff&files=&excludeFiles=&repos=
Bug: T352481
Change-Id: I8e19ee262a64b00742bb9203b2a2610ec0cc39fa
Promote the deprecation to an error in the context of PHPUnit tests. The
point of hard deprecations is to make tests fail and this will help with
that, and also with eventually promoting the deprecation to an error
outside of tests.
Adjust code in parser tests that was accessing MediaWikiServices via
Title too early.
Avoid hack of resetting the error handler after loading Setup.php, and
conditionally install MW's hadler instead. This is particularly
important in scenarios where an exception is thrown before the handler
is reset, because MW's exception handler may also access
MediaWikiServices.
Bug: T227900
Bug: T273261
Change-Id: I7c5234046379cf4abd25d65e78c0a99ac9f32600
Add utility methods to TestSetup and call them from the bootstrap file.
Also call the same method to load settings from
MediaWikiIntegrationTestCase when invoked via the unit tests entry
point. This also fixes a couple bug in the deferred setup scenario where
setLoadTestClassesAndNamespaces wasn't called, and the error handler
wasn't reset (T227900#9003435).
Make MediaWikiIntegrationTestCase not try to load settings more than
once. Trying to do so should probably be mostly harmless because of the
require_once usage, but it's also unnecessary and this change avoids any
chance of unwanted side effects.
Also use MW_INSTALL_PATH instead of $IP in bootstrap.php.
Bug: T227900
Change-Id: I7090976435e7e2d1264ee345e2670baaccf532ea
- Move handling of PHPUNIT_WIKI to the common bootstrap, the values
might be needed in integration tests.
- Add method to TestSetup for checking composer.lock, and use it in both
bootstraps. This cannot be moved to the common bootstrap yet, because
it needs to run after loading MW.
- In MediaWikiIntegrationTestCase::
initializeForStandardPhpunitEntrypointIfNeeded, use global $IP instead
of redefining it.
Bug: T227900
Change-Id: I050dcc36b814abd7b909eaaf6d356ecd0d3a0c80
$wgWikimediaJenkinsCI is not a configuration variable, so it needs to be
made explicitly global or it won't be available until the end of
Setup.php.
Bug: T341731
Bug: T90875
Change-Id: I49123a5021ef3770d0cb5f36044aad791368df37
`composer phpunit:entrypoint` should be used instead. Copy all the
setup to a new bootstrap file, with some adjustments for the bootstrap
not being in the global scope when PHPUnit loads it.
Leave the old script and bootstrap in place (e.g., for CI), but make
them print deprecation warnings.
Update the composer scripts to use the standard `phpunit` entrypoint.
The bootstrap code was copied almost verbatim from the phpunit.php
entrypoint to minimize changes. Any improvements can be done in other
patches.
Bug: T90875
Change-Id: I95a80c44f8d88c3c498efe1ae64008f0ff1eea55
In PHP < 8.1, the $GLOBALS variable doesn't follow the usual array
by-value semantics: $originalGlobals was actually a reference to the
$GLOBALS array. This means that its value might be different before and
after the require_once. See https://3v4l.org/BeUgm.
In turn, this leads to a bug when trying to replace phpunit.php, where
Wikibase's $wgWBClientSettings is set to the empty array by an extension
function. In turn, this causes the variable to be ignored by this method
because it wasn't in the original list of globals (and therefore it
wasn't put into the global state), but it was in $originalGlobals after
the require_once, which excluded it from being exported later. With that
variable's value missing, some tests that needed specific config were
being skipped.
Again, note that this is only an issue in Wikimedia CI when running PHP
7.4 jobs, and not elsewhere if PHP >= 8.1 is used (for instance, in
MediaWiki-Docker).
Bug: T90875
Change-Id: Ib1954ecf5a01df9b55c4d55cbeb61c7737d51f9f
We always wrap the local cluster cache, and there are no subclasses
of WANObjectCache. It was never documented or recommended how these
would be used. It is a left-over from the original 2015 Multi-DC plan
in which WANObjectCache would work differently. See task for details.
Note that this requires no configuration changes, even in the
theoretical case of these variables being used, as the only
option is to use the main cache, and that's also the default.
* Update WAN overrides to override the underlying main cache
instead.
* Fix EditPageTest which was previously implicitly using a 'hash'
as main cache but also relying on wan cache to be 'none'.
The part that it actually needs is the 'none'. When WAN cache is
enabled, testUpdateNoMinor fails due to an edit conflict because
one of the edits it makes is made with a current timestamp whereas
it expects to simulate wpEdittime in the year 2012 which, when
caching is enabled, is ignored and becomes the current time instead.
I don't understand exactly why, but I'm going to conserve that
behaviour for now.
* Fix TemplateCategoriesTest, which was failing due to an unexpected
cache hit:
> [objectcache] fetchOrRegenerate(…:page:10:…): volatile hit
This could be solved in a more realistic way by splitting the test,
or by explicitly resetting services half-way the test to clear
WikiPageFactory, PageStore and WANCache process state.
For now, keep the prior behaviour of no cache in this test.
Bug: T305093
Bug: T329680
Depends-On: If890622eed0d0f8b4bd73d36ba1815a3d760ea05
Depends-On: Ie1def75208822bdf19bb2cfd7e6edf32c2000e6b
Depends-On: I35cce61dc3ee90dcee3dd6f0b36f84133be029ed
Change-Id: I53781a8c06ebb2583f6ca83dd91bbfe8a5c88b13
TestSetup refers to wgLocalTZOffset instead of wgLocalTZoffset. This
doesn't break things for PHPUnit and CI (because this offset is defined
in the default configuration called by Setup), but, when calling
parserTests.php directly, the global is not defined correctly, leading
to issues with magic word parserTests.
Change-Id: Ic52e6e9c21c09bc74cc662d9f89769539185195d
None are used in WMF-deployed extensions and have been hard deprecated
for multiple releases as well.
Change-Id: I62cfa22291f81295b4908192de8657a750c6716d
This caused unexpected problems with no obvious fixes. Needs more work.
This reverts commit 7238dff532.
Bug: T310255
Bug: T90875
Change-Id: I3758cbb6d0029b20ec1b0f67dbf2f422031c50ae
* switch to phpunit.xml.dist instead of suites.xml
* switch composer.json to vendor/bin/phpunit
* tests/phpunit/phpunit.php is retained but will be removed after CI
jobs and other references on
codesearch (https://codesearch.wmcloud.org/search/?q=tests%2Fphpunit%2Fphpunit.php&i=nope&files=&excludeFiles=&repos=)
are removed
* add a default bootstrap.integration.php; unit tests in
composer.json use the non-MW bootstrap file (bootstrap.php)
* Migrate the phpunit.php logic into tests/phpunit/BootstrapIntegrationWrapper.php
Depends-On: I19d560bdcdb2ee914ab055e094841f2b5db8be55
Depends-On: Ib23209fc3b095e3c012ed84ce5c11f8b2d27b898
Co-authored-by: Daimona Eaytoy <daimona.wiki@gmail.com>
Bug: T227900
Bug: T90875
Change-Id: I82045c207738d152d5b0006f353637cfaa40bb66
Run phan over classes in tests/parser
The dependency of classes between parser and phpunit is not clear.
Classes used by both possible needs part of /common/
Change-Id: I2ceca6b7cd447876c127ed3b14e09f479defbd93
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
This was causing a fatal error when running some integration tests on
PHP 8.1: "FatalError: $wgBaseDirectory must not be modified in settings
files! Use the MW_INSTALL_PATH environment variable to override the
installation root directory." It seems it caused other (less obviously
related) errors as well.
The root cause was that TestSetup::requireOnceInGlobalScope() was
copying the values of globals to local scope, but didn't make the local
name an alias for the global. This meant that when code outside of the
current scope changed global variables, it wasn't reflected locally. Now
we instead declare all existing global variables as globals. This still
doesn't help if the included file declares a new variable and then it's
changed by code outside the current scope -- the new value will not be
reflected in the current scope. Hopefully this doesn't happen.
I don't understand why this bug didn't happen in versions before 8.1.
Presumably it's related somehow to changes in global handling in 8.1.
It seems like the best solution is to edit these files so they don't
expect to be in global scope to begin with -- just access globals only
via $GLOBALS.
Change-Id: I535aa31699d99cd08579b235c48784029c5d04b6
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
Also add a method for setting changes that should be reapplied after
loading the setting files, and set $wgShowHostnames in TestSetup, since
it seems like it may be useful when running all kind of tests.
Bug: T90875
Change-Id: I0d54c9a23f6cebf91bbb5a3a5f03b3d650e386e9
The parsing of the timecorrection useroption was split over multiple
classes. Combine into a single class and add some testcases.
Change-Id: I2cadac00e46dff2bc7d81ac2f294ea2ae4e72f47
Remove WRITE_SYNC flag from ChronologyProtector since the current
plan is to simply use a datacenter-local storage cluster.
Move the touched timestamps into the same stash key that holds the
replication positions. Update the ChronologyProtector::getTouched()
comments.
Also:
* Use $wgMainCacheType as a $wgChronologyProtectorStash fallback
since the main stash will be 'db-replicated' for most sites.
* Remove HashBagOStuff default for position store since that can
result in timeouts waiting on a write position index to appear
since the data does not actually persist accress requests.
* Rename ChronologyProtector::saveSessionReplicationPosition()
since it does not actually save replication positions to storage.
* Make ChronologyProtector::getTouched() check the "enabled" field.
* Allow mocking the current time in ChronologyProtector.
* Mark some internal methods with @internal.
* Migrate various comments from $wgMainStash to BagOStuff.
* Update some other ObjectCache related comments.
Bug: T254634
Change-Id: I0456f5d40a558122a1b50baf4ab400c5cf0b623d
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
To disable mail in tests, use setTemporaryHook after the
service container setup, instead of the soon-to-be deprecated
Hooks::register().
Change-Id: I84ea69feb0ebf81855b745c14fdba50d4e121de8
== Motivation
Mute a log channel, for which the Logger object is injected by
service wiring, for a service that is overridden by default,
such as 'DBLoadBalancerFactory'. For that, calling setLogger()
mid-test would be too late.
== Changes
* Add a test-only method to LegacyLogger that makes it possible
to change its `minimumLevel` attribute, thus making it turn
itself into a NullLogger if raised to infinity. This is the
same principle we use already for disabled log channels when
using MediaWiki normally (see LegacyLogger::__construct).
* Previously, the developer's LocalSettings.php was loaded
which includes the Spi configuration. This meant other Spi's
could be configured which means we might not be dealing with
a LegacyLogger object.
Similar to what we do with ObjectCache and JobQueue already,
make the default Spi in tests the same as the normal MW default.
* Add setNullLogger() which makes use of these two.
Bug: T248195
Change-Id: Ieade3585812de47342259afa765e230fff06f526
This removes Language::$dataCache without deprecation, because 1) I
don't know of a way to properly simulate it in the new paradigm, and 2)
I found no direct access to the member outside of the Language and
LanguageTest classes.
An earlier version of this patch (e4468a1d6b) had to be reverted
because of a massive slowdown on test runs. Based on some local testing,
this should fix the problem. Running all tests in languages is slowed
down by only around 20% instead of a factor of five, and memory usage is
actually reduced greatly (~350 MB -> ~200 MB). The slowdown is still not
great, but I assume it's par for the course for converting things to
services and is acceptable. If not, I can try to optimize further.
Bug: T231220
Bug: T231198
Bug: T231200
Bug: T201405
Change-Id: Ieadbd820379a006d8ad2d2e4a1e96241e172ec5a
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
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
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
Trying to avoid resetting services introduces a lot of complexity and
several bugs. We were doing a reset for 70% of @group Database tests
anyway.
Instead:
* Reset services at the start of MediaWikiTestCase::run().
* Capture the actual original service container instead of making a
special shared service container.
* The test-isolated local service container can now only be initialised
non-statically. Revert the recent conversion of overrideMwServices()
to static.
* Store a reference to the local service container in the test case
object. In MediaWikiTestCase, always use the original or local service
container directly, to avoid confusion about which one is active at
the time.
* Remove a lot of unnecessary teardown
* Always call ServiceContainer::destroy() before forceGlobalInstance()
since the memory is not otherwise freed.
Change-Id: I4a17c1c7ec92c14e3bc471f0216473ebe19477b9
