This is intended to isolate parser tests from other tests
by resetting the service locator between test runs, just like
MediaWikiTestCase does.
NOTE: this has no effect on parser tests run via parserTest.php,
it's only for tests run via PHPUnit.
Bug: T204065
Bug: T204072
Change-Id: I772b3b4a2d4d98948a249603b1cdb0933427b01c
* Instead of rewriting $argv, add a Command subclass called
MediaWikiPHPUnitCommand which overrides the configuration using the
stub functions in Command which were provided for that purpose.
* Revert c804a0b5b9, which added redundant debug output to tests,
and instead install the MediaWikiPHPUnitTestListener listener
unconditionally. Deprecate and make non-functional the --debug-tests
option. If you don't want tests to produce debug output, you can
always turn the channel off.
* Because I added our listener to the listener array instead of making
it override the printer, it's no longer necessary to derive from
PHPUnit\TextUI\ResultPrinter. Instead we derive from BaseTestListener.
So we don't need to call the (empty) parent methods.
* Remove the --with-phpunitclass feature since it doesn't work with this
scheme.
* Instead of passing CLI args to MediaWikiTestCase via a public static
variable, inject it non-statically by overriding the TestRunner and
TestResult.
* Remove --file, which has been non-functional since my 2016 refactor.
Change-Id: Ibcaf9ca81c8dc63cce6dc6f6fb1fffee19f8804e
With a separate service for each of the NameTableStore tables, it
wasn't possible to instantiate a NameTableStore for a foreign wiki,
leading to the inelegant situation of having RevisionStoreFactory
construct a new NameTableStoreFactory every time a RevisionStore for a
foreign wiki was requested. These NameTableStore objects were not
tracked in any structured way, so there was no way to reset them for
tests.
So, introduce NameTableStoreFactory, which tracks object instances for
both local and remote table access.
This also avoids having schema details in ServiceWiring.php.
Depends-On: I5c78cfb8bf90eca935a3264592366f63517c4fad
Bug: T202641
Change-Id: Ic0f2d1d94bad9dcc047ff19a1f92db89b7e014ce
In fact it always has zero rows. Well, at least it does until
ApiQuerySiteinfoTest::testInterwikiMap() inserts two rows without using
@group Database, and then it has two rows from then on. It's meant to
have zero rows.
This saves time and memory.
Revert of f17feae3a9
Change-Id: Ibdb12ff941d2cb47143bdff176072ef9078fa0f7
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
This ensure that the regex is escaped correctly,
even when the quoted value never contains the delimiter
Change-Id: I2dc93fa0154d4506c276a30cab008bc2ac5e0687
Log test setup, start and end to the tests-phpunit log channel. This
helps when interpreting debug logs. The channel name was chosen by
analogy with the existing tests-parser log channel.
Change-Id: I2bc87564247f2f136b2244d426fa127d21663f92
Resetting the content_model and slot_role tables between test runs
requires the corresponding NameTabelStore instances to be reset
as well. We may however have many of them, buried in various services.
There is no easy way to reset them consistently.
Letting information in these tables persist between tests seems
harmless. Tests that need these tables reset can simply add them
to the tablesUsed array.
This is needed for unit tests to work with the new MCR schema.
Bug: T198561
Change-Id: I63e61e1ab74e00c20930a83d3a3f5df53092a197
Calling SpecialPageFactory methods statically is now soft-deprecated.
SpecialPageFactory::resetList() is a no-op, and I changed tests
in core to use overrideMwServices() instead.
Methods that fell back to $wgUser now require a User object being passed.
Depends-On: Ie1f80315871085b9fd4763a265b588849d94414d
Change-Id: Id8a92d57743f790b7d8c377c033cef38d1bb24de
This fixes the following SQL error, when the interwikilinks table was
marked as used:
Fatal error: Uncaught exception 'Wikimedia\Rdbms\DBQueryError' with message 'A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: INSERT INTO `unittest_interwiki` (1,2,3) VALUES ('Array','Array','Array')
Function: MediaWikiTestCase::resetDB
iterator_to_array on the result of the select of the interwiki table
returns an array with the first entry having the key 1. For
multi insert to work, the array must start on 0.
Change-Id: I3dc1be9e2f016709f451fe6e8d7cc60862c1ffea
They are supposed to call overrideMwServices() instead, per
documentation. One test does call resetGlobalServices(), probably by
mistake. It can be private so other tests won't make the same mistake.
Change-Id: I11ed598fcc901d0d9951724f2d210d3a7a1482d2
This avoids error-prone code written separately in every test. In
addition to no existing tests resetting the TitleFormatter (more
services probably need to be reset as well), they mostly reset only the
namespace cache on $wgContLang, which wouldn't help for any other
language.
The parser test runner still doesn't do this, but maybe it should.
Change-Id: I44b7a1aec48f14b0950907fa14bd0df80f674296
Helper to skip tests if they're being run with a specific DBMS where the
test currently fails.
The main use case for this is to temporarily disable failing postgres
and sqlite tests so we can make those test runs voting (so we don't
regress any further), and re-enable the tests once they've been fixed.
Change-Id: I1fd7ca6b2d21fed59ed387376d03489c7cbccdfe
This adds a way to take any connection to the wiki database and
allow it to be used for unit tests.
This is needed to test code that requires two independent DB
connections, to the same database or to a different wiki's database.
Change-Id: I0b84a0c4d174cbde830786028ee7568c4ea9fb5d
Sometimes you need to create pages with a non-sysop.
Example: I31aedcb9af7584fa5504916c67ca10f205ec9910
Change-Id: I9e48f7c00efbce8c2de3f5db3a74462d47ae8f64
Enable inserts to the new MCR db schema in single slot mode only.
TODO:
- RELEASE NOTES
Notes:
- When in MIGRATION_WRITE_NEW or greater, deleting and then
restoring a page will result in different data in the revision table.
For example, if you delete a page that has text_ids present in the
revision table and restore it, the text_ids will be blank after.
- When in MIGRATION_WRITE_BOTH or greater the archive table will
start to ar_content_model entries where previously it would have been
given NULL. This is due to the old content schema having NULL in the db
when the default content model is used, but the new schema will always
have a value, taken from the content_models table
Note: If259b1e1c49ce was squashed into this change.
Bug: T183488
Bug: T174024
Change-Id: Ic2221da30c8f6ac2ba42720fcd568f2d0ed70534
Some unit tests for the MCR schema migration change the DB schema
in the test setup. However, addCoreDBData() will not work with the
modified schema. Since these tests don't actually need addCoreDBData()
to do anything, they can simply override it to do nothing.
Without this change, tests for Ic2221da30c and Ifabf39e12ba843
fail with $wgMultiContentRevisionSchemaMigrationStage = MIGRATION_WRITE_BOTH.
Change-Id: I86e140ec981dfa4e904822b1600399c533f9e3d6
MediaWikiTestCase truncates all the tables in the tablesUsed field
after each test. It should also do that before the first test of the
class.
Change-Id: I8c33be7b1bdd83559a9ea7803471a1f39e0eb870
As of 556c5cf464, postgres renames the `user` and `text` tables to
`mwuser` and `pagecontent` respectively. Have resetDB() explicitly
reset those tables when using postgres.
Bug: T195807
Change-Id: I5052dd663a4fb16389611cd2985b712fb9a15069
To follow up I39b0825c, this change replaces the existing non-unique
index on the column with a unique index, to help avoid some of these
sort of bugs in the future.
Bug: T193180
Change-Id: I932478c9c6a13210bc9dff75286d0f08da56682c
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
`$a <=> $b` returns `-1` if `$a` is lesser, `1` if `$b` is lesser,
and `0` if they are equal, which are exactly the values 'sort()'
callbacks are supposed to return.
It also enables the neat idiom `$a[x] <=> $b[x] ?: $a[y] <=> $b[y]`
to sort arrays of objects first by 'x', and by 'y' if they are equal.
* Replace a common pattern like `return $a < $b ? -1 : 1` with the
new operator (and similar patterns with the variables, the numbers
or the comparison inverted). Some of the uses were previously not
correctly handling the variables being equal; this is now
automatically fixed.
* Also replace `return $a - $b`, which is equivalent to `return
$a <=> $b` if both variables are integers but less intuitive.
* (Do not replace `return strcmp( $a, $b )`. It is also equivalent
when both variables are strings, but if any of the variables is not,
'strcmp()' converts it to a string before comparison, which could
give different results than '<=>', so changing this would require
careful review and isn't worth it.)
* Also replace `return $a > $b`, which presumably sort of works most
of the time (returns `1` if `$b` is lesser, and `0` if they are
equal or `$a` is lesser) but is erroneous.
Change-Id: I19a3d2fc8fcdb208c10330bd7a42c4e05d7f5cf3
This should fix the flaky unit test 'SiteStatsTest::testJobsCountGetCached',
which fails locally as follows, when run in isolation.
> 1) SiteStatsTest::testJobsCountGetCached
> A single job enqueued bumps jobscount stat to 1
> Failed asserting that 2 matches expected 1.
>
> /var/www/mediawiki/tests/phpunit/includes/SiteStatsTest.php:22
> /var/www/mediawiki/tests/phpunit/MediaWikiTestCase.php:421
> /var/www/mediawiki/maintenance/doMaintenance.php:94
Instrumenting JobQueueMemory::doBatchPush reveals the following
jobs to have been queued.
- MediaWikiTestCase->run/->addCoreDBData/::getTestSysop/..
../User->addGroup/UserGroupMembership->insert/..
> UserGroupExpiryJob (2)
- MediaWikiTestCase->run/->addCoreDBData/WikiPage->doEditContent/..
../WikiPage->{closure}/WikiPage->doEditUpdates/JobQueueGroup->lazyPush/..
> CategoryMembershipChangeJob
> HTMLCacheUpdateJob (2)
Fix this by adding clearing of job queues to doLightweightServiceReset()
in MediaWikiTestCase.
Also:
- Move the call to doLightweightServiceReset() from run() to setUp(),
where it is easier to understand in context. It still runs at the same
logical point because PHPUnit calls setUp() right before run().
- Remove redundant reset for WANObjectCache->clearProcessCache that
was both in setUp() and in doLightweightServiceReset().
- Simplify SiteStatsTest by removing the hardcoded delete() calls.
An alternative fix for the flaky unit test would've been to add
a delete() call to categoryMembershipChange, but rather than hardcoding
all possible jobs that TestCase or another test could make, it's easier
to just reset/delete them all between tests.
- Simplify SiteStatsTest by using the $cache reference directly instead
of roundtripping through MediaWikiServices. If for some reason
setService() didn't work, the test will fail either way because it must
match the one used by JobQueueGroup (TODO: Use injection!), and besides
the setService() method already has its own unit test.
Change-Id: Ia4b7871221c76c65eacf31915b515705a36940d5
