Use more specific and less fragile assertions whenever possible;
most tests don't need to examine the internals of the status so
closely. Use StatusValue::getMessages() when necessary.
Change-Id: Ie4b3ebc03abb0e352e82394ced6ab9e733c83fb4
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
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
* Triple backslash in regex should really be quadruple backslash
* Using the returned value of a void method
* Immediately overwritten array keys
* Duplicate array keys
* Foreach variable reuse
* sprintf() with too many params
* Incorrect reference usage
Change-Id: I3c649b543c9561a1614058c50f3847f663ff04df
If you store a WeakMap in the object, containing only circular
references in the values, then nothing is keeping the WeakMap alive and
it can be deleted along with its parent TempFSFile by the garbage
collector.
A WeakMap contains normal references to its values, so those normal
references can be marked by the GC like any other references.
Instead, store the WeakMap as a static property.
Bug: T332461
Bug: T332397
Change-Id: Idbaa1019c2bac3d1dd9b001753c2f4c0aaf66e98
Use a WeakMap to track references to TempFSFile instances if available
to avoid deprecation warnings for dynamic property creation on PHP 8.2.
Use an anonymous class rather than an stdClass to test the behavior in
TempFSFileTestTrait to verify that bind() does not trigger dynamic
property creation on PHP 8.2.
Also add a Phan stub for WeakMap for PHP 7.4.
Bug: T324894
Change-Id: Ic413c115e9ed1c750e175152094f3309628e777a
Follows I3ea6fb26296f (MySQLPlatformTest):
* Avoid uncertainty and make the code improvable/removable by explaining
what the suppression is for.
* Remove use of outdated AtEase, which hasn't been used in core tests
for several months (ref phpcs.xml), and more generally not in new code
in core or extensions (ref T253461).
Follows I12c17e327628 (FileBackendTest):
* I was going to similarly explain the reason by stating from the linked
task that it is for preg_match, and I was goingn to move the wholesale
suppression to just the getMockForAbstractClass() call that constructs
the FileBackend and thus triggers the issue.
* Instead, I've fixed the constructor to not pass a string there in the first
place as all non-string values are naturally invalid. Even if there is
a way to satisfy the regex with a non-string value that casts to a
valid string, that'd be an invalid value for a FileBackend name as it
pubicly documented as requiring a string, and internally also stored
and typed as assumed to be (after validation) a string.
* Change the valid test cases to be more representative of actually
intended-to-be-valid input, and actually-likely-attempted-but-invalid
input. The regex permits `[a-zA-Z0-9-_]` yet no numbers, capitals
or dashes were validated by the test, and no special characters
rejected by the test.
This follows If29780653 (c250d07bac) from 2019 which added these test
cases to improve code coverage without input from any (admitedly,
non-existent) active maintainers.
Bug: T313663
Change-Id: Ia326e17231a53c7102dcb116817a0c3830c510e4
This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
Follows-up I361fde0de7f4406bce6ed075ed397effa5be3359.
Per T253461, not mass-changing source code, but the use of the native
error silencing operator (@) is especially useful in tests because:
1. It requires any/all statements to be explicitly marked. The
suppressWarnings/restoreWarnings sections encourage developers to
be "lazy" and thus encapsulate more than needed if there are multiple
ones near each other, which would ignore potentially important
warnings in a test case, which is generally exactly the time when
it is really useful to get warnings etc.
2. It avoids leaking state, for example in LBFactoryTest the
assertFalse call would throw a PHPUnit assertion error (not meant
to be caught by the local catch), and thus won't reach
AtEase::restoreWarnings. This then causes later code to end up
in a mismatching state and creates a confusing error_reporting
state.
See .phpcs.xml, where the at operator is allowed for all test code.
Change-Id: I68d1725d685e0a7586468bc9de6dc29ceea31b8a
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
These are not only 100% identical to the actual code, but also:
* It's error-prone. Some are already wrong.
* These test…() functions are not meant to be called from
anywhere. What is the target audience for this documentation?
* There is a @dataProvider. What such @param tags actually do is
document the provider, but in an odd place. Just looking at
the provider should give the same information.
* The MediaWiki CodeSniffer allows to skip @param when there is
a @dataProvider, for the reasone listed.
Change-Id: I0f6f42f9a15776df944a0da48a50f9d5a2fb6349
Most of these are found by the not yet released I10559d8.
I remove the type MockObject in some cases when the calling
code really does not need to know if he get's a mock or the
real thing. However, I do this only in places that are very
closely related to the fixes.
Change-Id: I26a4c3c5a8ae141bf56161b52b54bce7e68f2e30
This should be the exact same. Its more a style change than anything.
So why do it then?
* I believe this is much less confusing than code mentioning a weird
"standard class". Barely anybody knows what this is, and what the
difference between "object" and "stdClass" is.
* The code is shorter.
* It's even faster. In my micro benchmark it's twice as fast.
Change-Id: I7ee0e8ae6d9264a89b6cd1dd861f0466ae620ccc
Instead, the constructors for FileJournal and NullFileJournal should be
treated as stable. I would have added @stable, but our linting doesn't
recognize it yet and doesn't let.
Bug: T235066
Change-Id: I7741055b4f00197d1346ebbfebc14f20238a06f3
Currently 62.79% coverage, 108/172 lines.
One oddity discovered during testing was that the "quick" variants of
most methods don't have an $opts parameter. It seems like just an
oversight, so I added it.
Bug: T234227
Change-Id: If2978065392cd6dcf693a588bb1ce6b5d43828f2
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
These are in preparation for making a TempFSFileFactory service, thus
the odd break-up into two files. I split it into a separate commit so
that we could verify that the same tests pass before and after the
conversion to service.
Tests cover everything except getUsableTempDirectory() (which I don't
see how to test), and register_shutdown_function()-related stuff (which
seems actually impossible to test without starting a new PHP process).
Change-Id: If61b7ea3e332adc2bceefc8e6879a9e9443c99dd
