[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