[wp-trac] [WordPress Trac] #46149: PHPUnit 8.x support
WordPress Trac
noreply at wordpress.org
Wed Aug 19 01:08:48 UTC 2020
#46149: PHPUnit 8.x support
--------------------------------------------+-----------------------
Reporter: SergeyBiryukov | Owner: netweb
Type: task (blessed) | Status: assigned
Priority: high | Milestone: 5.6
Component: Build/Test Tools | Version:
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests early | Focuses:
--------------------------------------------+-----------------------
Comment (by dd32):
Replying to [comment:32 jrf]:
> I understand the direction you all want to take, but cannot in good
conscience support it for the following reasons:
I totally understand your position here, and I want to state that your
input is incredibly valuable and the work you've done so far in adding
support is tremendous.
> 1. It really isn't as straight forward as outlined in the comments above
and I say so based on both my experience with other test code bases as
well as on the work I did for this ticket.
I totally agree, this isn't super straight forward (Implementation vs Trac
comments never match 1:1!), and will be messy, but it's the unfortunate
reality when building with tools that have a mismatch in PHP distributions
and user focus. If we only had to support one version of PHP, one version
of PHPUnit, and could enforce that our lives would be so much easier, but
WordPress would mostly be a developer-only tool at that point.
WordPress has been relatively lucky in that up until now, there hasn't
been any significant changes like this language syntax change that cause
such problems.
> 2. It will raise the barrier for entry to new contributors by a factor
five as they will need to learn new (undocumented) names for fixtures,
assertions etc The PHPUnit knowledge they already have becomes next to
useless, the PHPUnit manual can no longer be used as reference etc.
They will still be able to use their own knowledge, it's just that come PR
time / patch time, whomever merges/commits would just need to check that
the correct functions are in use.
Developers writing WordPress PHPUnit tests will still need to figure out
all of our unit test factories, custom assertion methods, etc, this is far
from the only change/knowledge they'd need to get up to speed on.
A unit test could even scan the tests looking for non-prefixed cases to
make it easier for all.
> 3. It will alienate existing contributors to the tests.
This has always been a struggle with WordPress, be it PHP 5.2 vs 5.3 OOP,
PHP 5.2 vs 7.0, and now PHP 5.6 vs 7.1. If done correctly, I would hope
that the narrow functionality of PHPUnit that we do use would just work
and most contributors wouldn't notice a thing.
> 4. I truly believe our time would be better spend on making WP
compatible with newer PHP versions, than on a huge undertaking of making
the unit test suite compatible with PHPUnit 5 - 9.
I do believe that too - WordPress should be, and has to be, compatible
with newer PHP versions, but that shouldn't have to mean dropping support
for older versions of PHP.
----
There's an alternative option we have here too, we could standardise on
PHP8 + PHPUnit9 for *all* tests and rely upon a PHP transpile process to
run it on older PHP versions / PHPUnit versions. I attempted that with
PHP7.4/PHPUnit7 as a base and a [https://github.com/WordPress/wordpress-
develop/compare/master...dd32:try/php8-transpiling transpile (let's be
honest, regex..) to PHP8] which would work for travis unit testing, but
falls over because we can't force everyone to use PHP7.4 for unit test
development, hopefully PHP8 would be common soon.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/46149#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list