WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 8 days ago

#46149 assigned task (blessed)

PHPUnit 8.x support

Reported by: SergeyBiryukov Owned by: netweb
Milestone: Future Release Priority: high
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch has-unit-tests early php8 needs-dev-note
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Background: #43218

PHPUnit 8.0.0 is scheduled for February 2019. The changelog includes some backwards compatibility breaks.

From the PHPUnit 7 announcement (February 2, 2018):

Looking Forward

The following methods do not have a return value and should therefore have a void return type declaration:

  • PHPUnit\Framework\TestCase::setUpBeforeClass()
  • PHPUnit\Framework\TestCase::setUp()
  • PHPUnit\Framework\TestCase::assertPreConditions()
  • PHPUnit\Framework\TestCase::assertPostConditions()
  • PHPUnit\Framework\TestCase::tearDown()
  • PHPUnit\Framework\TestCase::tearDownAfterClass()
  • PHPUnit\Framework\TestCase::onNotSuccessfulTest()

These methods will have a void return type declaration in PHPUnit 8. Please declare your methods that overwrite the above mentioned methods void now so you are not affected by this backward compatibility break.

This is now implemented in PHPUnit 8, so our method signatures are no longer compatible and cause fatal errors:

Fatal error: Declaration of WP_UnitTestCase_Base::setUpBeforeClass() must be compatible with PHPUnit\Framework\TestCase::setUpBeforeClass(): void in tests/phpunit/includes/abstract-testcase.php on line 1110

We could look into using different signatures for different PHPUnit versions in the same way as in [44701]. However, given the large number of tests extending the ::setUp() and ::tearDown() methods, it's probably easier to address this when we bump the required PHP version to 7.1.

Change History (49)

#1 @desrosj
21 months ago

  • Milestone changed from Awaiting Review to Future Release
  • Type changed from defect (bug) to task (blessed)

#2 @SergeyBiryukov
21 months ago

We could also look into displaying a friendly message instead of a fatal error. Something like:

Looks like you're using PHPUnit 8.x, WordPress currently is only compatible with PHPUnit 7.x. Please use the latest PHPUnit version from the 7.x branch.

#3 @SergeyBiryukov
21 months ago

In 44723:

Build/Test Tools: Display a message about currently supported PHPUnit branch to avoid fatal errors on later versions.

See #46149.

#4 @desrosj
21 months ago

PHPUnit 8.0 and 8.0.1 have officially been released.

#5 @desrosj
21 months ago

Noticed today that the PHP nightly build is now failing from the changes in #43218. This should be fixed when the needed changes are made for this ticket.

https://travis-ci.org/WordPress/wordpress-develop/jobs/490350822

#6 @pento
21 months ago

Nightly switched from PHP 7.4 to PHP 8.0. #46235 is for adding PHP 7.4 back to the test matrix.

#7 @conner_bw
18 months ago

Please consider upgrading. I ran into this issue today trying to setup pcov:

https://github.com/krakjoe/pcov

Requires phpunit v8. Improves code coverage performance significantly.

#8 @ZanderZ
11 months ago

In February, PHPUnit 7 support will end and only PHPUnit 8 and 9 (to be released on February 7) will be supported.

The tickets says "it's probably easier to address this when we bump the required PHP version to 7."
Is there any news related to that?

#9 @davidshq
10 months ago

Also interested to hear a status update on this.

#10 @johnbillion
10 months ago

  • Keywords needs-patch added

There isn't one. If someone wants to work on this, that would be great.

#11 follow-ups: @SergeyBiryukov
10 months ago

Note that this still depends on bumping the required PHP version to 7.

As of this time, the decision has not been made yet.

#12 @netweb
10 months ago

  • Owner set to netweb
  • Status changed from new to assigned

I've partially implemented this for a client, will work on bringing those changes here

#13 in reply to: ↑ 11 @ZanderZ
8 months ago

Replying to SergeyBiryukov:

Note that this still depends on bumping the required PHP version to 7.

As of this time, the decision has not been made yet.

There has been 0 news on this front since the initial announcement. That announcement said "Depending upon feedback and effectiveness, we can follow up by bumping the required PHP version to 7 as early as December 2019." but that timeframe has clearly passed.

Can the WP team please share some news on this?

This ticket was mentioned in Slack in #core by sergey. View the logs.


6 months ago

#15 in reply to: ↑ 11 @SergeyBiryukov
6 months ago

  • Description modified (diff)

Replying to SergeyBiryukov:

Note that this still depends on bumping the required PHP version to 7.

Just to clarify, bumping the required version to PHP 7.0 is apparently not enough, as the void return type declarations only appeared in PHP 7.1. So to support PHPUnit 8.x, we'd need PHP 7.1 as the minimum required version.

Updating the ticket description accordingly.

#16 follow-up: @jrf
2 months ago

As per #50902 - we will never be able to get proper insight into the issues which need fixing on PHP 8 without making the testsuite compatible with PHPUnit 8 + 9.

PHPUnit 9.3.x was released a week ago and is the first PHPUnit version which is officially claiming support for PHP 8.0.

As per the WP 5.6 release planning support for PHP 5.6 will be dropped in WP 5.6.

Is there an official decision yet that PHP 7.1 (or higher) will be the new minimum ? If so, I'd willing to create an initial patch to fix the test suite.

#17 in reply to: ↑ 16 @SergeyBiryukov
2 months ago

  • Milestone changed from Future Release to 5.6

Replying to jrf:

Is there an official decision yet that PHP 7.1 (or higher) will be the new minimum ? If so, I'd willing to create an initial patch to fix the test suite.

No official decision yet, but I'm pretty sure that is the goal that was agreed upon in the May 11th Site Health meeting (Slack logs).

Since PHP 8 support is also one of the WP 5.6 focuses, and PHPUnit 8+ is a prerequisite for that, let's proceed with this.

Last edited 2 months ago by SergeyBiryukov (previous) (diff)

This ticket was mentioned in PR #483 on WordPress/wordpress-develop by jrfnl.


2 months ago

  • Keywords has-patch has-unit-tests added; needs-patch removed

Trac ticket: https://core.trac.wordpress.org/ticket/46149

The commits in this PR combined:

  • Bump the minimum supported PHP version for WordPress to PHP 7.1.26.

The "patch" part of the version number - 7.1.patch - is open for discussion, please see commit https://github.com/WordPress/wordpress-develop/commit/e913a6889a05cee5dab9a4eb2f3727029199076a for my argumentation for this specific version.

  • Applies the proposed patch for trac #50902 to allow the unit tests to run on PHP 8.0/nightly.
  • Bumps the supported PHPUnit versions to ^7.5 || ^8.0 || ^9.0.
  • Removes now redundant backfills for PHPUnit native functionality.
  • Adds a few polyfills for new PHPUnit functionality in PHPunit-version based traits.
  • Comprehensively applies any and all fixes needed to make the complete test suite compatible with PHPUnit 8.x and 9.x.

This PR will be easiest to review by looking at the individual commits and their detailed commit messages.

Once the patch from ticket 50902 and the patches from this PR are merged, we will be able to get proper insight into the problems we need to solve to make WordPress compatible with PHP 8.0 based on the existing tests.

Trac ticket 50913 already contains a couple of patches to make a start with PHP 8.0 compatibility.

Expanding the test suite, strict type checking in the test suite (Trac 38266) and code coverage tracking (Trac 46373) combined with adding @covers annotations (Trac 39265) to get better insight into which parts of the code base need more tests, is strongly recommended all the same.

#19 @prbot
2 months ago

jrfnl commented on PR #483:

Closing as the patch got linked to the wrong Trac ticket.

This ticket was mentioned in PR #484 on WordPress/wordpress-develop by jrfnl.


2 months ago

Trac ticket: https://core.trac.wordpress.org/ticket/46149

The commits in this PR combined:

  • Bump the minimum supported PHP version for WordPress to PHP 7.1.26.

The "patch" part of the version number - 7.1.patch - is open for discussion, please see commit https://github.com/WordPress/wordpress-develop/commit/e913a6889a05cee5dab9a4eb2f3727029199076a for my argumentation for this specific version.

  • Applies the proposed patch for Trac #50902 to allow the unit tests to run on PHP 8.0/nightly.
  • Bumps the supported PHPUnit versions to ^7.5 || ^8.0 || ^9.0.
  • Removes now redundant backfills for PHPUnit native functionality.
  • Adds a few polyfills for new PHPUnit functionality in PHPunit-version based traits.
  • Comprehensively applies any and all fixes needed to make the complete test suite compatible with PHPUnit 8.x and 9.x.

This PR will be easiest to review by looking at the individual commits and their detailed commit messages.

Once the patch from ticket #50902 and the patches from this PR are merged, we will be able to get proper insight into the problems we need to solve to make WordPress compatible with PHP 8.0 based on the existing tests.

Trac ticket #50913 already contains a couple of patches to make a start with PHP 8.0 compatibility.

Expanding the test suite, strict type checking in the test suite (Trac #38266) and code coverage tracking (Trac #46373)) combined with adding @covers annotations (Trac #39265) to get better insight into which parts of the code base need more tests, is strongly recommended all the same.

#21 @jrf
2 months ago

Please see the GitHub PR for a comprehensive set of patches to address this ticket.

#22 @prbot
2 months ago

jrfnl commented on PR #484:

@ntwb Thanks for the review! I've left replies to all remarks.

#23 @jrf
2 months ago

Before I forget to mention it: the "WP version bump" commit does not have to be included in the commits for this ticket, however, as the patches for this ticket require to stop testing against PHP < 7.1, it seemed like a logical commit to include.


After this ticket has been addressed, I would like to suggest follow-up tickets to address the following additional points in the test suite:

  • Review any @requires and version_compare()'s et al in the test suite to see if any of these can be removed now the requirements have changed.
  • Review any disabled tests (like commented out tests) to see if they were disabled due to version requirements not being met.
  • Review if the includes/phpunit6/compat.php file can be removed completely.

Similarly, after the version bump patch has been committed, follow-up tickets should be opened for the following additional points:

  • Removing the random_compat library. This library is no longer needed when the minimum PHP requirement is PHP 7.1. (Similar to #47699 for the PHP < 5.6 drop)
  • Go through the compat.php file to see if there are other PHP polyfills which can be removed. (Similar to #47698 for the PHP < 5.6 drop)
  • Go through the code base to review any code using version_compare(), function_exists(), defined(), extension_loaded() et al to verify whether these kind of toggles are still needed and remove them whenever possible. (Similar to #48074 for the PHP < 5.6 drop)
  • Updating external PHP dependencies if an update was so far blocked by a minimum PHP version mismatch.
Last edited 2 months ago by jrf (previous) (diff)

#24 @prbot
2 months ago

ntwb commented on PR #484:

Thanks @jrfnl , a few more thoughts:

### PHP 5.6 support:

  • https://wordpress.org/about/stats/
  • PHP 5.6 = 15.1%
  • This pretty much rules out PHP 5.6 being dropped in WP 5.6, that usage is far too high to consider dropping it, the considerations historically have been to consider if usage drops below 5%

### PHPUnit test matrix

  • PHPUnit 8.x supports PHP 7.2, 7.3
  • PHPUnit 9.x supports PHP 7.3, 7.4 & 8.0

Would it be worth setting up or changing the existing jobs to use newer versions of PHPUnit?

  • PHP 7.2 using PHPUnit 8.x
  • PHP 7.3 and/or 7.4 using PHPUnit 9.x

#25 @prbot
2 months ago

ntwb commented on PR #484:

Taking a read of the #site-health chat logs

The numbers for PHP 5.6 are similar to those we had for < 5.6 when we last bumped the version for WordPress 5.2, so it seems like we could bump the minimum to PHP 7.0 by the end of year as is. We do want to bump to PHP 7.1, though (as that would unblock using PHPUnit 8+ in core and testing WordPress on PHP 8), and we need additional efforts for that.

Given that we're still releasing security updates for WP 3.7 (released almost 7 years ago), it's not like we're leaving PHP 5.6 or 7.0 users without security updates, they just won't have some latest and greatest features of WP 5.6+, which seems fair.

A good first step might be to highlight PHP 7.0 as no longer "acceptable" in Browse Happy dashboard widget, same as we currently do for 5.6.

That's some reassuring news

Just noted the RECOMMENDED_PHP value in servehappy-config.php is still at 7.3. It was bumped 18 months ago in https://meta.trac.wordpress.org/changeset/7990.

Per the comment, it's supposed to be "The latest branch of PHP which WordPress.org recommends".

Given that 7.3 support ends in 5 months, should this be updated to 7.4?

Some things to note:

Ok, that's also some good steps


I'm somewhat more optimistic now having read the entire site #site-health Slack channel history since May 11 🤞🏼

#26 @jrf
2 months ago

Hmm.. something weird going on with the GH bot as my response which should be between those last two comments did not get cross-posted.

Quoting it here now for completeness:

This pretty much rules out PHP 5.6 being dropped in WP 5.6, that usage is far too high to consider dropping it, the considerations historically have been to consider if usage drops below 5%

@ntwb Dropping PHP 5.6 support is on the roadmap for WP 5.6, so IMO this is a foregone conclusion.

I did ask for confirmation before working on this patch and wouldn't have bothered spending this much time on getting it set up if that intention hadn't been clarified.

Would it be worth setting up or changing the existing jobs to use newer versions of PHPUnit?

No, that is not an option because of the void return type introduced for all fixtures in PHPUnit 8.
Return types were only introduced in PHP 7.0, the void return type in PHP 7.1, so it is not easy to make the test suite cross-version compatible with both PHPUnit 7 as well as PHPUnit 8 if the test suite also still has to be compatible with PHP 5.6/7.0.

There is a way to do it, but I would strongly recommend against it if it can be avoided in any conceivable way. IMO dropping support for PHP 5.6 and 7.0 is the much better choice.

Last edited 2 months ago by jrf (previous) (diff)

#27 @jrf
2 months ago

  • Keywords early added
  • Priority changed from normal to high

Ticket #51043 has been created to handle the version bump specifically.

#28 follow-up: @dd32
2 months ago

FWIW after looking through this and doing some non-trivial testing, I think it'd be best to get PHP8 unit tests running ASAP, with the assumption that PHP 5.6 support is going to stick around for a bit longer, probably until at least until the end of the year - and even if it doesn't, getting unit tests running on a not-too-far-away PHP8 is more important than that decision.

That means that migrating to using :void doesn't appear to be possible quite yet.

After talking through things with an unnamed committer, I suspect the best option might be to shim the functions in question.

  • Move from setUp() to something prefixed like _setUp() in all the actual Unit Tests (plus all the other newly void functions)
  • Conditionally load a WP_UnitTestCase class which defines setUp() as either non-void for older PHPUnits+PHPs or with Void for newer PHPUnits, which calls said _setUp() method instead.
  • Use Traits (PHP 5.4+) as per PR 484 to polyfill newer PHPUnit functionality
  • Migrate all the tests to the newer test syntax, as with PR 484.

That might mean that we'd ultimately end up with a phpunit-[5-9]/testcase.php file set, but that seems like a more reasonable framework to ensure that going forward we'll have a framework in place to support future PHPUnit/PHP syntax changes.

Related to that.. I've PR'd the wpdev images to add a PHPUnit9 image and use it for PHP 8 Since it's the only version that is supported there.

Last edited 2 months ago by dd32 (previous) (diff)

#29 @jorbin
2 months ago

I think the approach @dd32 is suggesting is going to be the best route for us. Supporting multiple versions of PHPunit is an unfortunate reality, but one that will help us not just now but also possibly farther into the future. While the ultimate goal of WordPress supporting only the versions of PHP that the PHP core team supports (which is the policy in place for PHPUnit) is admirable, until hosts are updating PHP versions with more regularity, it isn't something that I see becoming a reality any time soon.

#30 @ayeshrajans
2 months ago

I doubt Symfony's PHPUnit bridge will be able to make WordPress's test suite compatible across 5 PHPUnit versions, having a single test suite that works with multiple PHPUnit versions is one if its goals: https://symfony.com/doc/current/components/phpunit_bridge.html

#31 @pputzer
2 months ago

While problably not "production-ready" for Core, you can take https://github.com/mundschenk-at/phpunit-cross-version as a proof of concept for cross-version PHPUnit tests based on the Symfony phpunit-bridge. Caveat: Newer PHPUnit versions require their particular file naming conventions for individual test classes for separate execution (complete test suite works fine even when you use WordPress conventions).

Last edited 2 months ago by pputzer (previous) (diff)

#32 follow-ups: @jrf
2 months ago

I understand the direction you all want to take, but cannot in good conscience support it for the following reasons:

  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.
  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.
  3. It will alienate existing contributors to the tests.
  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.

So good luck to you. I wish you well.

#33 in reply to: ↑ 32 @dd32
2 months ago

Replying to 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.

  1. 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.

  1. 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.

  1. 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 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.

#35 in reply to: ↑ 28 @dd32
2 months ago

Replying to dd32:

I suspect the best option might be to shim the functions in question.

I went ahead and put something together that does just that, it's not super pretty, but it does work on PHP 5.6 -> 8.0 with PHPUnit 5 -> 9.

Most importantly, it introduces a way to shim functionality from newer PHPUnits for older PHPUnit versions, so the tests can immediately use the new functionality from PHPUnit 9 - it just has to include a compat method for the older versions.

Unfortunately it did require ceasing using the setUp() (and friends) methods directly, as there's simply no way to have those functions defined AND work on all current supported PHPs.
For now, I've simply prefixed those methods with an underscore, we do have custom wpSetUpBeforeClass() and wpTearDownAfterClass() methods though, we could probably do the same for the setUp()/etc.

I think this will affect plugins in some way or another, but if they're affected they'd have had to change their testing to work with PHP8 anyway.

My primary goal here was to get unit testing for PHP 5.6-8.0 running for core, so that there was a possibility to actually see the PHP 8 Unit test status..

To reduce the diff size for review, all of the code changes to the tests are done through a bash script, mostly based on @jrf's PR, only the changes to the test runner framework is in the PR as a code change.

If you want to see the complete changes to the tests, you can run the ./tools/migrate-test-syntax.sh script locally or look around line 200 of the Travis tests for a 16,000 line diff.

Here's the PR and hopefully, all the Travis tests will pass.. except for PHP8.. which well you'll see :)
edit: Seems the PR Travis tests are all failing on the PR, but passing on the fork branch..

Last edited 2 months ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #core by jorbin. View the logs.


2 months ago

#38 in reply to: ↑ 32 ; follow-up: @dd32
2 months ago

Replying to jrf:

  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.

@jrf I'd like to bow down to you and agree with you. I apologise for doubting you. It's not realistic to follow what I outlined above. It works, but it's not worth it, and it's a support burden that can't be carried forward.

I've taken my above PR and forked it into a new PR 491 which does two things, which I think is a reasonable middleground

  • Standardises on PHPUnit8/9 assert calls, requires PHP 7.2+ to run. (edit: 7.1+ but lets say 7.2 for future compat)
  • Includes a bash script for use on Travis to remove the void return type hinting so that Travis can still run the Unit tests for PHP 5.6, 7.0 , and 7.1 (edit: Not needed for 7.1 yet)

There are two bash scripts included, one of which will be required to be bundled for Travis:

  • tools/migrate-test-syntax.sh Responsible for doing some automated changes to the codebase that's needed for PHPUnit8/9 support - @jrf did a better job than this script in PR484 but this let me test that PHP8 support was working without making the PR diff huge.
  • tools/tests-old-php.sh It's responsible for removing the PHP 7.2+ syntax (Right now, just the void return type hinting) so that the tests will run on PHP 5.6-7.1 with PHPUnit 5-6. This one is going to be needed on Travis, It could be done just be done inline in .travis.yml but I'm assuming that we might end up adding other things when PHPUnit 10 comes out next year, so it seems worth while including it separately, which also allows developers to run it locally if needed.

The PHPUnit Compat traits that I've got in there are super minimal and just pass it through to other assertion methods that should exist. I did it slightly different to PR484 which makes it far easier and simpler as we don't have to use matching function definitions, nor check if the native function exists. PR484 has better PHPDocs though.

There's a bunch of other cleanups that can be done, but I didn't look into, such as using the PHPUnit namespaces and the SpeedTrap changes.

all of the unit tests run with only PHP8 failing due to some Core changes needed and some test alterations that I couldn't easily automate.

Last edited 2 months ago by dd32 (previous) (diff)

#39 @prbot
2 months ago

dd32 commented on PR #489:

The changes proposed in this PR are not viable, this PR was forked into #491

#40 in reply to: ↑ 38 @SergeyBiryukov
2 months ago

Replying to dd32:

I've taken my above PR and forked it into a new PR 491 which does two things, which I think is a reasonable middleground

  • Standardises on PHPUnit8/9 assert calls, requires PHP 7.2+ to run.
  • Includes a bash script for use on Travis to remove the void return type hinting so that Travis can still run the Unit tests for PHP 5.6, 7.0, and 7.1.

Just noting that the void return type hinting was introduced in PHP 7.1, so unless I'm missing something, PHP 7.1 should be able to run the newer syntax without any modifications, I think they are only needed for 5.6 and 7.0. Is that assumption wrong?

#41 follow-up: @jrf
2 months ago

Just noting that the void return type hinting was introduced in PHP 7.1, so unless I'm missing something, PHP 7.1 should be able to run the newer syntax without any modifications, I think they are only needed for 5.6 and 7.0. Is that assumption wrong?

Yes and no. Void is not the problem for PHP 7.1. The problem there is that PHPUnit 7 is still needed - PHPUnit 8 has a minimum requirement of PHP 7.2 - and if per @dd32 comment above, the test suite will be standardized on PHPUnit8/9 assert calls (which I support as the sensible thing to do), then some of those assertions will either need wrappers, like the traits I created in the original PR, or the proposed bash script will need to run to "rewrite" some of those assertions to their old name/ to the old way of doing that assertion.

#42 in reply to: ↑ 41 @SergeyBiryukov
2 months ago

Replying to jrf:

Yes and no. Void is not the problem for PHP 7.1. The problem there is that PHPUnit 7 is still needed

Ah, that makes sense. Thanks for the clarification!

#43 @dd32
2 months ago

I did indeed mix PHP 7.1/7.2 and PHPUnit 8/9 requirements up.
The bash script isn't currently needed for PHP 7.1 as the void return type hints work there.

However, as @jrf suggested, if we're going to take this route (Which in all honesty, is the only way forward I can see) it makes zero sense to recommend PHPUnit 7 / PHP 7.1 be natively supported by the tests - It may still just work, but we shouldn't advocate it's use, and we have to assume that it won't always run without run-time modifications in the future.

#44 @hellofromTonya
8 weeks ago

  • Keywords php8 added

Adding the php8 keyword to group it with the PHP8 tickets.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


8 weeks ago

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


7 weeks ago

#47 @desrosj
7 weeks ago

  • Keywords needs-dev-note added

Adding needs-dev-note. Detailing things to be aware of related to unit testing and PHP 8 should be outlined.

#48 @prbot
7 weeks ago

dd32 commented on PR #491:

This is no longer needed, as the work has been done by others.

#49 @SergeyBiryukov
8 days ago

  • Milestone changed from 5.6 to Future Release

PHPUnit 8.x/9.x support would be great to have, but is complicated if we also have to support PHP 5.6 and 7.0 at the same time.

Currently, we have the tests running on PHP 8 with PHPUnit 7.5.x, as result of the changes in #50902, specifically [48957] and [49037]. It's not pretty, but does the job for now. So I think the best way forward at the moment would be to continue with PHPUnit 7.5.x, as that already works.

Since core no longer requires PHPUnit 9.x support for PHP 8 testing, I'm moving this to a Future Release to be explored separately. Once the minimum required PHP version is bumped to 7.1 or later, this should be easier to address.

Note: See TracTickets for help on using tickets.