ObjectCache is already doing a lot of factory pattern logic like
creating instances of the various BagOStuff, this should really be
the responsibility of the factory servicet.
This patch introduces a proper factory (ObjectCacheFactory) to handle
the responsibility of creating various instances of BagOStuff. Since
`newFromParams()` is a static function that gets passed in configuration
of $wgObjectCaches, that can stay that way (to keep supporting how we do
this in prod today).
Technical Breaking Change: `ObjectCache::makeLocalServerCache()` now has
a parameter and requires it but there are no callers of this method outside
MW core hence it is safe to change (and this patch update all callers) to
work correctly. Cache prefix is gotten from global state because sometimes
at this stage, the services container is not available.
Bug: T358346
Change-Id: I3179a387486377c6a575d173f39f82870c49c321
The idea is for all entry points to use the MediaWikiEntryPoint
base class, to improve consistency and testability.
Bug: T354216
Change-Id: I3678afe32c7c1a313d2dcb1808286c25ecd167eb
Allow extensions with very special modules that can't be called in a
testing environment to skip ResourcesTest::testRespond().
Needed by If1186797fd047d4f for ext.wikisource.OCR.
Change-Id: Id02915d9633c2d8209d2ff2e60f6748095ec10fe
Update cases where one of the IConnectionProvider methods is called
immediately.
This doesn't really change anything, but I hope it helps promote
getConnectionProvider() as the common way to do this.
Follow-up to 8604c384f6.
Change-Id: Id0e7d02bab0c570343c2b1f03c70b44ee39db112
Follow up Id9ab64fc8b09d9 which made listTables() consistently exclude
views.
Hard deprecate Database::listViews() which was only used for view
filtering of listTables(), conditional on database type.
Add an integration test for the new listTables() behaviour.
Change-Id: I3402a227f92b35192c6385c6aeab461de43b9f58
Changes to the use statements done automatically via script
Addition of missing use statements and changes to docs done manually
Change-Id: Ib326ae1e5c8409a98398c721e8b8ce42c73bd012
Also fix callers that were checking for t/f.
In CASE and COALESCE expressions, using 't' and 'f' did actually work,
because those literals have an unknown type and the other argument is
boolean, so PG coerces them to boolean. But it seems safer and clearer
to use the strongly typed literals TRUE and FALSE.
Bug: T352229
Change-Id: Ia01b76d3d6d2e048feac8e3118d9faff63a9ac56
Several methods on the Content interface had been deprecated in 1.35 and
1.36 in favor of corresponding methods on the ContentHandler base class,
to allow implementations of these methods to use proper dependency
injection. This patch removes backwards compatibility support for
subclasses that were overriding these methods.
Change-Id: I8e474a1cc4dec760a7f6db25e4b313392f3723b1
* Unrelated to the ResourcesTest structure test as it isn't testing
any of core's resources.
* Moved to the libs/Minify repo in change Ia9018a966a5325d.
Change-Id: If87035777633635fe4ad0f01790e7084f56f65a0
Make message to actually communicate errors instead of
confirming success, this will reduce confusion like in T348934
Change-Id: I0b9cd5aed26be539db429a79c486217a69f74cdb
Moved to docs/ rather than includes/, update references and remove
from phan exclusion list
Follow-up: I32c034d05bf2354cdaa5f02d19031421cbae78a1
Change-Id: I8d71c29c8cbfa413db47066f00d71783259f0916
In order to check all existing rate limits through Authority, the limit
keys must function as user rights. However, we do not want them to be
"normal" permissions, since they cannot sensibly be revoked, and they
should not clutter the user interface.
To solve this, we introduce the concept of "implicit rights", which are
always granted, but limitable.
Change-Id: I0ea6f29130da1d68d022d47d9221fe878bc9beae
The method should never be called directly, so make it throw an exception.
Nonetheless, mark it as deprecated and detect overrides in the
constructor, so that anyone who tries to override this method will see a
warning.
Fix the few tests that were relying on the existence of the test page.
Bug: T342428
Depends-On: Ic64ded5e2c0b59e7c888ece9566076058a125be4
Change-Id: I308617427309815062d54c14f3438cab31b08a73
If the test expects the user to exist, it should use getTestSysop to
guarantee the account creation. Otherwise, use mocks or different
usernames to clarify that the username is not relevant to the test.
Change-Id: I87a27f01e1874af410e5d43e2e7fc3b10bb14eb8
This is an intermediate step towards the linked bug, to help untangle
the performance impacts.
Bug: T343407
Change-Id: I086f173f811fb44683f4a67bf6bc415d7e27f593
Mock the needed dependencies to avoid database access when possible, and
add the test to the Database group otherwise.
Bug: T155147
Change-Id: Ic5c39ab35ab4d993721713285180f072497a5a40
We would like to remove DB access in non-database PHPUnit tests. As a
first step, avoid database usage in tested code when possible. In
particular:
- In NameTableStoreFactory, avoid domain ID normalization if the
provided ID is already false.
- In SpecialDoubleRedirects, do not acquire a DB connection until it's
needed (which is just one place).
- Use editPage() in TitleDefTest instead of a DIY implementation, and
add `@group Database` accordingly.
- Avoid parsing titles in ContentHandler tests that don't need to parse
titles. Among the many dependencies of parsing titles is the interwiki
lookup, which requires DB access.
- Also remove test cases that used the "Gadget" namespace; it doesn't
exist in core, so these pages were actually in the mainspace.
- Mock the database in CategoriesRdfTest. The only two methods that use
the database were already being mocked.
- Add `@group Database` to test classes that are intentionally using the
Database, mainly via getTestUser().
Bug: T155147
Change-Id: I9385fe14cfeb6b7b7378cc322d510034c4ee0711
TestUser creates the user and therefore needs the database. Avoid using
it in non-database tests.
Add ApiQueryBlockInfoTraitTest to the Database group because it needs
the database.
Add DeleteUserEmailTest to the Database group because since 3bedffa8
the default user is not created any more in non-database tests
Change-Id: Iff438964dde47a47a2fa4a314d55010bd8c7fee5
Some non-database tests are currently accessing the database. Fixing
them means either avoiding the DB access if it's possible and makes
sense for the test, or adding the `Database` group otherwise. In
particular:
- Replace global/static functions with services in a couple places to
make testing easier.
- RevisionRendererTest needs to be in the Database group due to heavy
global state usage (including DB) by Parser
- ActionFactoryIntegrationTest and SpecialPageFatalTest should be in
the database group because they test many different classes, and some
of which may use the database in the tested methods.
- SpecialUserLogoutTest must be in the database group because of User.
- Some pager tests are using wfGetDB directly.
Change-Id: I96eb2acf9a2cbfd17e81225db2773d5e8e30260b
This tests needs the database in various places:
SqlModuleDependencyStore, wfGetDB() for WikiModule::preloadTitleInfo,
and other things in WikiModule. Some of these might be avoided; for
instance, it could use KeyValueDependencyStore. Others can't really be
avoided as the relevant classes call wfGetDB (or equivalent methods in
MediaWikiServices) directly.
Given the importance of this test, I'd rather have it continue using the
database, so add it to the Database group.
Change-Id: I564a826e97967897a3538d74cdef6f3dbdd570f1
Since the latter is going to be removed, make sure that the former has
everything we need. In particular:
- Add failOnRisky=true from suite.xml
- Reorder config options and add comment about stderr from suite.xml
- Remove non-existent tests/phpunit/skins and
tests/phpunit/documentation from the test suites. These cause an error
when trying to run all the suites with `composer phpunit`.
- Leave the other suites as they are. Compared to suite.xml,
phpunit.xml.dist has separate suites for core, extensions, and skins
unit tests.
- Leave includeUncoveredFiles to false. The rationale in
I3d19627fa36f6cc6666c29fdb638272fdaa30630 seems convincing. CI already
sets it to true: https://w.wiki/72qE
- Leave slowThreshold to 100 as per
Ia6ed404d4d4cc8a7b4b8a48b232f644f400f8103. I believe that change
simply missed suite.xml. The same rationale that led to the threshold
being increased for unit tests is valid a fortiori for integration
tests, which are generally slower.
Rename SuiteDirectoryTest and make it check phpunit.xml.dist too.
Bug: T227900
Change-Id: Ib4b47b337870dffc61dd44817a21d11809075d5b
Some of the methods called in the data provider, like getAllowedParams,
may make read queries. This should be avoided in data providers (see
e.g. T312849). Instantiate the module in the test method instead, and
process all parameters there. This does mean that a failure with a
single parameter will make the test end without testing the remaining
parameters, but there isn't much we can do about it.
Bug: T341731
Change-Id: I7eeed0da5da61e90c6fbfa0411a2b3b416395167
Going forward we do not want to use the targets system in the way
we traditionally used it. While updating existing usages will take
time it seems like it might be a good idea to prevent additional usages
being added. This list would gradually be updated as we update those
components.
Bug: T127268
Depends-On: Ibd7270abc5f223bc4f4814c896e7ef4d02d21386
Change-Id: I2e226c174be88caeb505738645cfa0582e39a197
