4ef0891994
Notable changes: * In SqlBagOStuff::getConnectionFromServerInfo, only two loggers were injected. The rest implicitly got a NullLogger due to being absent. These are now effectively unsilenced. * Database::__construct() required almost all parameters, even the loggers. I've wanted to move some of DatabaseFactory into the ctor here for a while. In order to make this change not a breaking change, the new 'logger' parameter is optional with NullLogger as default. This allowed some of the test cases, which were simply passing NullLogger, to be fixed by passing nothing instead of passing the new option name. The Database class is behind a dozen layers of indirection for real use, so this will still be injected just fine (DBF, LB, LBF, MWLBF, etc.). * In LegacyLogger, the handling for $wgDBerrorLog was previously limited to DBConnection and DBQuery. This now includes errors from other (generally, newer) parts of Rdbms as well, which were previously missing. This only affects sites (typically CI and dev setup) where $wgDBerrorLog is used, as opposed to the more common $wgDebugLogGroups by-channel configuration. * TransactionProfiler gets its logger injected in a rather odd way, via entrypoints (MediaWiki.php, ApiMain.php, and MaintenanceRunner) as opposed to service wiring. This is kept as-is for now. * In LBFactoryTest, in particular testInvalidSelectDBIndependent2, there are cases that intentionally produce failures of which the result is then observed. In CI we assert that dberror.log is empty so instead of adding the missing logger fields to that LBFactory instance, the only one set (replLogger) is removed. The alternative is to set 'logger' now, which would naturally cause CI failures due to unexpected entries coming through to non-mocked error log. Bug: T320873 Change-Id: I7ca996618e41b93f488cb5c4de82000bb36e0dd3 |
||
|---|---|---|
| .. | ||
| data | ||
| docs | ||
| includes | ||
| integration/includes | ||
| languages | ||
| maintenance | ||
| mocks | ||
| structure | ||
| suites | ||
| tests | ||
| unit | ||
| bootstrap.maintenance.php | ||
| bootstrap.php | ||
| HamcrestPHPUnitIntegration.php | ||
| LessFileCompilationTest.php | ||
| MediaWikiCliOptions.php | ||
| MediaWikiCoversValidator.php | ||
| MediaWikiGroupValidator.php | ||
| MediaWikiIntegrationTestCase.php | ||
| MediaWikiLangTestCase.php | ||
| MediaWikiLoggerPHPUnitExtension.php | ||
| MediaWikiPHPUnitResultPrinter.php | ||
| MediaWikiTestCaseTrait.php | ||
| MediaWikiUnitTestCase.php | ||
| MWTestDox.php | ||
| phpunit.php | ||
| README.md | ||
| ResourceLoaderTestCase.php | ||
| suite.xml | ||
MediaWiki PHPUnit tests
WARNING: Integration tests may be destructive and alter or remove parts of your local database. We try to use temporary tables where possible, but you must never run tests on a production server or on a wiki where you don't want to lose data.
Running tests
If you haven't already, run composer update (specifically without --no-dev) in the MediaWiki core directory. This will install PHPUnit.
To read about how to run specific tests, refer to:
https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Running_the_tests
Writing tests
A guide to writing PHPUnit tests for MediaWiki can be found at: