Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[6.x] PHPUnit 9 support #30947

Merged
merged 2 commits into from Dec 27, 2019
Merged

[6.x] PHPUnit 9 support #30947

merged 2 commits into from Dec 27, 2019

Conversation

@GrahamCampbell
Copy link
Member

GrahamCampbell commented Dec 26, 2019

Why Laravel 6 and not 7?

It is highly likely that PHPUnit 8 won't work in at least one of PHP 8.0, 8.1, 8.2, or 8.3. Since Laravel 6.0 is LTS, it is likely that we will want to continue to support newer versions of PHP, and so we need to be able to run on the latest PHPUnit.

Why use graham-campbell/testbench-core?

PHPUnit 8 deprecated assertArraySubset and Laravel ported the code over, but in PHPUnit 9, this port no longer works. Much more work is needed for PHPUnit 9, and moreover, the code for PHPUnit 9 won't work in PHPUnit 8 due to difference interfaces. Luckily, we can use my testbench core package, which handles this mess.

NB There does exist another package that backports assertArraySubset, but it appears to be abandoned already, and doesn't work on PHPUnit 9.

Why the branching code in src/Illuminate/Foundation/Testing/Assert.php?

In order to maintain BC, if people are using PHPUnit 8, we use Laravel's existing code. There are 3 cases to consider:

  1. If graham-campbell/testbench-core is installed, always use its implementation.
  2. If not installed and we are on PHPUnit 8, use Laravel's existing backport.
  3. If not installed and we are on PHPUnit 9, then we throw an exception whenever someone tries to use the method.

What to do in Laravel 7?

Perhaps we should remove Laravel's internal backport entirely, and depend on my testbench core package? This PR doesn't deal with that.

@mfn

This comment has been minimized.

Copy link
Contributor

mfn commented Dec 26, 2019

Just wanted to voice that I praise the forward thinking to support "at some point older Laravel version with newer dependencies", especially for PHPUnit.

I've experienced this myself that sometimes the Laravel upgrade can't be performed in a timely manner (big project, big dependencies, inferior test suite, etc.) but it's still nice to be able to use newer versions of the dependent libraries, if it's only to already prepare as much as possible before the actual upgrade.

So, thanks 👍

@GrahamCampbell GrahamCampbell mentioned this pull request Dec 26, 2019
@taylorotwell taylorotwell merged commit 5cf26ec into 6.x Dec 27, 2019
4 checks passed
4 checks passed
continuous-integration/styleci/pr The analysis has passed
Details
continuous-integration/styleci/push The analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@GrahamCampbell GrahamCampbell deleted the phpunit9 branch Dec 27, 2019
@driesvints

This comment has been minimized.

Copy link
Member

driesvints commented Dec 30, 2019

Can't we just require graham-campbell/testbench-core in the "require" dependencies and remove the if statement?

@GrahamCampbell

This comment has been minimized.

Copy link
Member Author

GrahamCampbell commented Dec 30, 2019

Can't we just require graham-campbell/testbench-core in the "require" dependencies and remove the if statement?

I was planning on adding this to the default laravel/laravel require-dev in 7.x.

@GrahamCampbell

This comment has been minimized.

Copy link
Member Author

GrahamCampbell commented Dec 30, 2019

Can't we just require graham-campbell/testbench-core in the "require" dependencies and remove the if statement?

The other problem with doing this is that people end up with testbench-core when they didn't want dev deps.

@driesvints

This comment has been minimized.

Copy link
Member

driesvints commented Dec 30, 2019

@GrahamCampbell but your package has 0 dependencies and just a handful of classes? I can't see how that would be a bad thing.

@GrahamCampbell

This comment has been minimized.

Copy link
Member Author

GrahamCampbell commented Dec 30, 2019

My package does actually depend on phpunit. It just isn't listed as an explicit dependency, to account for people possibly wanting phpunit as a phar. I wouldn't recommend loading my package without phpunit, otherwise autoloading some of the classes will crash the interpreter.

@GrahamCampbell

This comment has been minimized.

Copy link
Member Author

GrahamCampbell commented Dec 30, 2019

In particular, I'd expect it to cause problems with preloading.

@GrahamCampbell

This comment has been minimized.

Copy link
Member Author

GrahamCampbell commented Dec 30, 2019

TBH, I think it's fine not to require it. Like, we don't require mockery or phpunit within the framework. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.