Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I4ff4d0c10820dc2a3b8419b4115fadf81a76f7a2
This patch introduces a namespace declaration for the
MediaWiki\FileBackend to FileBackendGroup and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Id33b6bfa56131978900199786b0082481c6c54a5
This patch introduces a namespace declaration for the
Wikimedia\FileBackend to FileBackend and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Id897687b1d679fd7d179e3a32e617aae10ebff33
FileBackendIntegrationTest was running tests against different backends
in an unconventional way, using a combination of wrapper test cases that
run tests against two different classes, and CLI options which don't
really exist anymore and have an associated fixme.
So:
* Move the bulk of FileBackendIntegrationTest to a new abstract base
class under tests/phpunit/integration.
* Add subclasses for the FS and multiwrite test cases. This allows us to
eliminate the wrappers.
* Add a subclass for MemoryFileBackend.
* Add a Swift subclass which replaces the main use case for
the CLI option --use-filebackend. It is automatically enabled when
a Swift backend is configured, similar to PostgreSQL tests.
* Some miscellaneous tests with a medium level of integration, not
requiring backend setup and teardown, were moved to new classes
FileBackendMultiWriteTest and FileBackendStoreTest.
Change-Id: I0da531349d7627970a7bcb34f3c1f5fd7e05cb21
Follows-up I4c7d826c7ec654b, I1287f3979aba1bf1.
We lose useful coverage and spend valuable time keeping these accurate
through refactors (or worse, forget to do so). The theoretically "bad"
accidental coverage is almost never actually bad.
Having said that, I'm not removing them wholesale (yet). I've audited
each of these specific files to confirm it is a general test of the
specified subject class, and also kept it limited to those specified
classes. That's imho more than 100% of the benefit for less than 1%
of the cost (more because `@covers` is more valuable than the fragile
and corrosive individual private method tracking in tests that
inevitably get out of date with no local incentive to keep them up to
date).
Cases like structure tests keep `@coversNothing` etc and we still don't
count coverage of other classes. There may be a handful of large
legacy classes where some methods are effectively class-like in
complexity and that's why it's good for PHPUnit to offer the precision
instrument but that doesn't meant we have to use that by-default for
everything.
I think best practice is to write good narrow unit tests, that reflect
how the code should be used in practice. Not to write bad tests and
hide part of its coverage within the same class or even namespace.
Fortunately, that's generally what we do already it's just that we
also kept these annotations still in many cases.
This wastes time to keep methods in sync, time to realize (and fix)
when other people inevitably didn't keep them in sync, time to find
uncovered code only to realize it is already covered, time for a less
experienced engineer to feel obligate to and do write a low quality
test to cover the "missing" branch in an unrealistic way, time wasted
in on-boarding by using such "bad" tests as example for how to use
the code and then having to unlearn it months/years later, loss of
telemetry in knowing what code actually isn't propertly tested due to
being masked by a bad test, and lost oppertunities to find actually
ununused/unreachable code and to think about how to instead structure
the code such that maybe that code can be removed.
------
Especially cases like LBFactoryTest.php were getting out of hand,
and in GlobalIdGeneratorTest.php we even resorted to reminding people
with inline comments to keep tags in sync.
Change-Id: I69b5385868cc6b451e5f2ebec9539694968bf58c
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
And also assertNotRegExp -> assertDoesNotMatchRegularExpression. The
methods were renamed in PHPUnit 9.
Done automatically with:
grep -rl assertRegExp tests/ | xargs sed -r -i "s/>assertRegExp\(/>assertMatchesRegularExpression\(/"
grep -rl assertNotRegExp tests/ | xargs sed -r -i "s/>assertNotRegExp\(/>assertDoesNotMatchRegularExpression\(/"
Split out from Ifdba0f9e98eb6bce4590b7eb73170c51a697d7c6 so that it
remains smaller and easier to review.
Also make a test use MediaWikiUnitTestCase (it's already in the unit/
dir) so that it can access the forward-compat method.
Bug: T243600
Change-Id: Ifa279d5f201d7abeebece292141ebface8278046
It calls the Shell class, which uses MediaWikiServices. Why was this not
causing test failures on CI?
Change-Id: Id953c1425659ede158034988dd652b59a0e9811b
Make IResultWrapper inherit from SeekableIterator instead of Iterator.
As suggested by the interface documentation, throw an
OutOfBoundsException when the seek is out of bounds, instead of failing
in subtle ways.
Change-Id: I60427bc9057677254f1b06177ec525f1ae917721
Cleanup after the switch of Database::query() to return ResultWrapper
instead of resource.
* Soft-deprecate the IResultWrapper accessors in IDatabase.
* Move relevant DBMS-specific functionality to ResultWrapper subclasses.
The deprecated methods in IResultWrapper become short and simple.
ResultWrapper is now abstract (b/c break).
* Move the implementation of fieldName(), numFields() and one of the
fieldInfo() implementations to the ResultWrapper subclass in order to
avoid ResultWrapper::unwrap() calls.
* Make Database::doQuery() return a ResultWrapper subclass instead of
underlying result data, so that the Database parent class does not
need to be aware of wrapper construction.
* Hard-deprecate ResultWrapper::unwrap(),
DatabaseMysqlBase::fieldType(), DatabasePostgres::fieldType().
* Fix the inefficient seeking method in SQLite.
* Make FakeResultWrapper extend ResultWrapper with an implementation
similar to the SQLite one. This is possible because ResultWrapper does
not depend on IDatabase anymore.
* Resolve fixme in DatabasePostgres: from studying the source,
neither pg_fetch_object() nor pg_num_rows() can set an error
retrievable with pg_last_error(). Removed unnecessary warning
suppression.
* ResultWrapperTest didn't make sense as a unit test anymore, so I
adapted it as an integration test against the current DBMS.
This change also means that ResultWrapper::key() always gives the
correct offset, even if Iterator methods are not being used.
Bug: T286694
Change-Id: I935835316c0bd7d3d061bd8fde9c9ce99ce756ec
