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
Expected value is the first parameter to assertSame() or assertEquals().
And turn to use assertCount() for some assertions aginst count of array.
Based on code search `assert(?:Same|Equals)\(.+,.+expected` and I look
through files roughly, so some assertions that don't contains 'expected'
are also fixed. In the meantime, some assertions that I am not clear
about are not touched.
Change-Id: I75798b60d29fd19b33f4fdf34ed3c788db420d01
From:
https://docs.openstack.org/swift/latest/overview_expiring_objects.html
The swift-object-expirer offers scheduled deletion of objects.
The Swift client would use the X-Delete-At or X-Delete-After
headers during an object PUT or POST and the cluster would
automatically quit serving that object at the specified time
and would shortly thereafter remove the object from the system.
Bug: T280496
Change-Id: I886f3cea51f80d820841f8548941ca02a0a514c3
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
In addition:
* Remove restriction that Content-Type was ignored in 'copy' and 'move'.
* Fix failing tests due to copy/move not respecting 'ignoreMissingSource'
when using doQuickOperations().
Change-Id: Id1befeefeaaf75f0a6bf0e68b1e62271d432f953
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
libcurl adds 'Content-Type: application/x-www-form-urlencoded'
to a POST request if the 'Content-Type' header is not set
manually. Because data in swift is updated via POST, the
Content-Type header must be set explicitly to stop a run of
refreshFileHeaders.php from changing the Content-Type of all
files in swift to application/x-www-form-urlencoded
Bug: T178849
Change-Id: I43c21bc1b73e37104cf07cd5f1c1557f472b9898
Replaces \TestingAccessWrapper (defined in core) with
\Wikimedia\TestingAccessWrapper (defined in the composer package
wikimedia/testing-access-wrapper).
See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper
for downstream patches.
The core version of the class is kept around for a while to avoid
circular dependency problems.
Bug: T163434
Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
It's up to the developer to choose the level of granularity they are
aspiring for in their test coverage. But that granularity level should be
reflected in @covers. When you have hundreds of lines of code testing a
single-line function (FileBackend::doOperation), that's a good hint that
something went wrong.
FileBackendTest is 2700 lines of code and appears to be aiming to test
the whole filebackend module. So I adjusted @covers to reflect that.
Change-Id: Iacd8cf475d1761c3b32c739983343619a9509d6b
PHP_CodeCoverage_Exception:
> Trying to @cover not existing method "SwiftFileBackend::sanitzeHdrs".
> Trying to @cover not existing method "LineFormatter::normalizeException".
> Trying to @cover not existing method "MonologSpi::mergeConfig".
> Trying to @cover not existing method "ProcessCacheLRU::het".
> Trying to @cover not existing method "BitmapHandler::swapICCProfile".
> Trying to @cover not existing class or interface "checkParseSafety".
> Trying to @cover not existing method "Article::__call". (was removed).
> Trying to @cover not existing method "ExtensionProcessor::extracttExtensionMessagesFiles".
> Trying to @cover not existing method "FileContentsHasher::getFileContentHash".
Makes code coverage run fail at the moment. These used to be warnings
in PHPUnit 3.x, but are now hard exceptions in PHPUnit 4.x when requesting
a coverage report.
Change-Id: If7f45ca57fd7d480d35b1414a889398837c0c472
- Removed space after cast
- Removed spaces in array index
- Removed double spaces
- Added spaces around string concat
- Fixed mixed tabs and spaces at begin of line
Change-Id: I38e849723f055d2d4c05cba72f5c245a28e8d5da
