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
