Already soft-deprecated in 726f10b, which also removed the
unused assertTypeOrValue() method without deprecation.
Change-Id: I0d417bf79f03e899dccfa469f639c04d4cf999cf
assertArrayEquals is a generic assertion that does not have anything
to do with integration testing, and is quite useful for isolated
testing of classes which return unordered sets.
Change-Id: I45af77402a1bc922579aff14b21874ec8680e765
*assertType is marked as deprecated, and should ideally be removed soon
(i.e. no hard deprecation to follow)
*Most usages of assertType in core were autofixed by using I8ef556b630812aeea77c5606713f53d9af609f1b
*assertTypeOrValue was removed because only used in SiteTest
(codesearch: https://codesearch.wmflabs.org/search/?q=assertTypeOrValue&i=nope&files=&repos=)
*SiteTest::assertTypeOrFalse was removed because unused
Bug: T192167
Change-Id: Icb3014b8fe7d1c43e64a37e0bdaaffec18bb482f
We've decided to switch to PHPUnit 7 to make things easier. This also
means that we shouldn't suppress PHPUnit 8 warnings, otherwise we cannot
know if tests are already compatible with PHPUnit 8.
Note that the trait is not deleted, because it may still be necessary
for single tests -- we're just not including it by default. However, it
is now deprecated, and its use is discouraged.
Bug: T192167
Change-Id: If90e6b6ffe03dfb117ec2b4b13c79983fe1bd0f2
The class PHPMaintClass is meant to be loaded when running phpunit.php
which is only done when running tests with it. When running tests by
using the bootstrap file only, e.g. in an IDE, this class will not be
available. Relying on it in other classes will therefore break them.
Moving the required parts to another outside class and add it to the
test autoloader. My feeling says, that adding the PHPMaintClass to the
autoloader says "NOOOO", that's why I added a new one.
There also seems to be some CI builds failing because of that:
https://integration.wikimedia.org/ci/hob/quibble-vendor-mysql-php72-docker/30642/console
Bug: T151101
Change-Id: I33e27009657a951173694fc847973560a1ce967b
This is moved out of the main PHPUnit upgrade commit to allow
extensions to silence their warnings beforehand, to avoid breaking
their tests.
Bug: T192167
Change-Id: I60379a933a3a1b018d9f5ef6b51019002389dda3
These were made final in PHPUnit8. Since there seems to be no easy way
to work around that, partially revert
Ibcaf9ca81c8dc63cce6dc6f6fb1fffee19f8804e and start using static
properties again (cfr. T192167#5550034).
Split from Ic14f5debc53e55d67146dc96279d26dfd52b4000.
Bug: T192167
Change-Id: I3fe163738662ae41eb275a0327cb33187290a70f
No repo should be using PHPUnit4 features anymore. Removing this trait
from the test classes is the first step towards the complete removal,
see I84694e32c06f1f0f9fb8398b1f2b92d3df599ddb.
Bug: T192167
Change-Id: I60e66259ea920e84573ae99293b005306876b325
There is no reason this should be necessary. Resetting services should
do the trick, together with Language::$mLangObjCache while it exists.
Resetting only a subset of services is fragile and shouldn't be done,
because one of the reset services might later be injected into a service
that's not reset, resulting in bugs.
Change-Id: I8c72b466ba7337649f9256ee6c078c76163f9785
Otherwise bugs can be caused by services that hold stale service
references. These are very annoying to track down.
Change-Id: Id9e5a8a0fa3493af0855f4bf1816175ecff6136a
These appear to be unused. Moreover, their behavior doesn't match their
documentation. getDefault() claims to return NullLockManager if no lock
manager could be found, but really returns it if there's no lock manager
named 'default'. getAny() claims to throw if no lock manager can be
found, but actually throws if no lock manager is named 'default' or
'fsLockManager'. The behavior can be easily replicated by just using
get() yourself and catching any exception.
Bug: T234227
Change-Id: Iad083847f45d6e017a3f7dbfece1f9c155c5efd6
This a second attempt at 09407afd74, which was reverted due
to breaking Wikibase integration tests.
The original commit had two separate typos that made it not work at all.
Additionally, some things were apparently expecting $wgContLang to be an
actual Language and not a StubObject. To solve that, we just set it
directly and don't use a StubObject. Initialization should be cheap, and
it would probably have been unstubbed on every test anyway.
Bug: T231799
Change-Id: I6d68a22e53e17458d0a63c13bd97c19baff4d1c7
Languages with variants no longer can override the parent's constructor
(which is now used for injecting services). Instead, they need to
override Language::newConverter().
Bug: T201405
Change-Id: I923400d61763cf1db88cb0c3f684c9c10e58032d
This removes the requirement that setUp() and tearDown() in the derived
class need to call the parent.
Change-Id: I9d4771c28160356ff58884e3a58fa28c8db4e8a5
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 patch allows PageUpdaterTest and DerivedPageDataUpdaterTest to
function properly. Without this patch, the fail when run by themselves.
See phab ticket for analysis.
Bug: T234031
Change-Id: I0804b503bc8b860343a5141c0bfb25fe6855c87d
This was inspired by I1b2a6eb. As far as I can tell this patch does not
change anything in terms of behavior. My main motivation was to get rid
of the (possibly confusing) duplications, and turn them into a loop.
The special case where TestUserRegistry::clear() is executed appears like
it might not do the exact same as before, but I'm pretty sure it does.
Before, the special case was executed whenever any of the user tables was
present in the $tablesUsed array originally passed to the method. The
same still happens.
Additional changes:
* Strict type hints in the method signature.
Change-Id: I7f292095c0dac99b9cc0b0aa5ce10703f24f8bba
For example, leftover cruft in `log_search` will cause spurious
associated_rev links between unrelated revisions and log entries.
Bug: T227849
Change-Id: Ie344522229e4142f2c61a267b4d693051b813236
Test the intersection of $tablesUsed with each set of tables
separately and only update it afterwards. Without this fix, overlaps
between the table groups would cause additional groups to be pulled in
unnecessarily.
Change-Id: I1b2a6eb47e061dee8a27fb4779809b4684c05104
When a change tag row is written during a test, it links to content IDs which
may be reused in future tests. To maintain test isolation, we should include
this table in the rollback for any tests that touch pages.
Bug: T227849
Change-Id: I98fe17e209f6c685ad87e52886a3526f35645d1e
100% unit test coverage for FileJournal and NullFileJournal. 100%
integration test coverage for DBFileJournal. Unit tests for
DBFileJournal once it supports injection.
I removed FileJournal and NullFileJournal from the list of classes that
FileBackendTest tests. It doesn't actually test them, it just happens to
run code from them without checking its correctness at all.
Depends-On: Ic22075bb5e81b7c2c4c1b8647547aa55306a10a7
Change-Id: I46d10ab7b87c23937aa04d7ec1922abfcf3bd611
We already reset $wgParser to a stub in a number of places where it
might have changed. Let's give $wgContLang the same treatment so we can
avoid special-case code.
This deprecates setContentLang(), which is no longer needed. The magic
of $wgContLang is now handled by setMwGlobals() and setService().
This is a follow-up to e4f69ee, which fixed one case of this problem.
Change-Id: I90925ef8b2a7478cce90d474db1b8b4539e45c15
