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
Partially revert 74b4d669a7. Type checks were removed on the
basis that they are redundant with the PHP warnings raised by
array_key_exists(), but PHP 8.0 does not raise such warnings. The
PHP 8.0 migration doc says: "The behavior of array_key_exists()
regarding the type of the key parameter has been made consistent with
isset() and normal array access. All key types now use the usual
coercions and array/object keys throw a TypeError."
We could just remove the tests, but the original rationale does stand,
since without this change, we have
> $m = new MapCacheLRU(4);
> $m->set(3.4, 'x');
> print $m->get(3, 'x');
x
without any warning, which seems surprising.
Bug: T283275
Change-Id: I3628daef21611ff3f6bc252f105deed886ce8088
In commit 70c2223843, the explicit type checks were added as
exceptions because WMF's infra at the time didn't capture stacktraces
for the native warnings that PHP already emits.
That infra issue was resolved years ago (T45086), so we can remove
these again.
I've kept one manual type check, which is in setField, because for
$field in that method we don't first check existence (which emits
the warning normally), and because it does an assignment rather than
a key check, and assignments in PHP still have some invalid types
that don't emit warnings (specifically, booleans).
Bug: T275673
Change-Id: I72388f069afc345da9e9aac330733da49714d1b4
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
2019-06-13 22:56:31 +02:00
Renamed from tests/phpunit/includes/libs/MapCacheLRUTest.php (Browse further)
