You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The PHPUnit\Framework\TestCase::prophesize method not polyfilled #62
PHPUnit\Framework\TestCase::prophesize() is deprecated and will be removed in PHPUnit 10. Please use the trait provided by phpspec/prophecy-phpunit.
I can't just require phpspec/prophecy-phpunit in the composer.json and use the trait it provides, because package itself won't even connect in PHP 7.2 and smaller versions.
Unfortunately, I don't see a straight forward way to solve this from within the PHPUnit Polyfills library as the same Composer restrictions apply.
As far as I know, Composer does not have an option to conditionally install a package based on the PHP version, so the PHPUnit Polyfills library can't (conditionally) require it either.
The only thing I can currently think of - and this is quite hacky - is to have a conditional composer require --dev for phpspec/prophecy-phpunit as part of a post-install-cmd/post-update-cmd script, but as scripts are only executed for the "root" project, this is still not something which could be handled by the PHPUnit Polyfills.
The only thing the Polyfills could do is provide a trait which would either load the trait provided by phpspec/prophecy-phpunit or call the PHPUnit\Framework\TestCase::prophesize() method depending on the availability of either, but that would still require that the "root" project would add the post-install-cmd/post-update-cmd to require the phpspec/prophecy-phpunit package depending on the PHP version detected, so it wouldn't work out of the box.
The only other thing I can think of, would be for the phpspec/prophecy-phpunit library to widen the requirements and add the "fall-through to PHPUnit" trait for PHP < 7.2 there....
The only other thing I can think of, would be for the phpspec/prophecy-phpunit library to widen the requirements and add the "fall-through to PHPUnit" trait for PHP < 7.2 there....
@stof FYI and if it helps, we did something similar to what I propose above for the rdohms/phpunit-arraysubset-asserts package, where the real functionality in the repo is used in combination with the supported PHP and PHPUnit versions, but where the package is still allowed to be installed in combination with older PHP/PHPUnit versions, in which case it falls through to the PHPUnit native functionality as included in the older PHPUnit versions.
@jrfnl@aik099 I would welcome a PR extending the supported PHPUnit versions, with a condition definition of the trait being either empty or the current one.
Alternatively, I could put those back in draft and pull them after the PR addressing this issue, but that's up to @stof. The currently open PRs are very minor small changes, so should be easy merges.
The currently opened PRs are not at all a blocker for that change anyway (bumping the min prophecy version does not impact the definition of the trait at all for instance). So you should be able to create the PR.
I'll do some rebasing tomorrow, as, as I said before, the PRs make changes in the same files, so will be creating conflicts when pulled at the same time. Guess I'll just keep recreating commits and rebasing :-/
I'm going to close this issue as this is not something which I intend to solve in the polyfills (forward compatibility vs backward compatibility). The PR to https://github.com/phpspec/prophecy-phpunit is (still) open and if it would be merged, I'll happily link to it from the readme of this package, but other than that, there is nothing to be done here.
Activity
jrfnl commentedon Oct 31, 2021
@aik099 Thanks for opening an issue about this.
Unfortunately, I don't see a straight forward way to solve this from within the PHPUnit Polyfills library as the same Composer restrictions apply.
As far as I know, Composer does not have an option to conditionally install a package based on the PHP version, so the PHPUnit Polyfills library can't (conditionally) require it either.
The only thing I can currently think of - and this is quite hacky - is to have a conditional
composer require --devforphpspec/prophecy-phpunitas part of apost-install-cmd/post-update-cmdscript, but as scripts are only executed for the "root" project, this is still not something which could be handled by the PHPUnit Polyfills.The only thing the Polyfills could do is provide a
traitwhich would either load the trait provided byphpspec/prophecy-phpunitor call thePHPUnit\Framework\TestCase::prophesize()method depending on the availability of either, but that would still require that the "root" project would add thepost-install-cmd/post-update-cmdtorequirethephpspec/prophecy-phpunitpackage depending on the PHP version detected, so it wouldn't work out of the box.The only other thing I can think of, would be for the
phpspec/prophecy-phpunitlibrary to widen the requirements and add the "fall-through to PHPUnit" trait for PHP < 7.2 there....Ideas/suggestions/PRs for solutions welcome....
@Seldaek @sebastianbergmann Would you happen to have any bright ideas on this subject ?
aik099 commentedon Nov 1, 2021
@stof, any way to make https://github.com/phpspec/prophecy-phpunit work on other PHP versions?
jrfnl commentedon Nov 1, 2021
@stof FYI and if it helps, we did something similar to what I propose above for the
rdohms/phpunit-arraysubset-assertspackage, where the real functionality in the repo is used in combination with the supported PHP and PHPUnit versions, but where the package is still allowed to be installed in combination with older PHP/PHPUnit versions, in which case it falls through to the PHPUnit native functionality as included in the older PHPUnit versions.For reference:
rdohms/phpunit-arraysubset-asserts#11
rdohms/phpunit-arraysubset-asserts#48
If you think a similar solution would be acceptable for
phpspec/prophecy-phpunit, I'd be willing to help get that set up.Seldaek commentedon Nov 1, 2021
Sorry i don't see a better way than what you suggested above.
jrfnl commentedon Nov 1, 2021
@Seldaek Thanks Jordi for giving this a look-over!
stof commentedon Nov 2, 2021
@jrfnl @aik099 I would welcome a PR extending the supported PHPUnit versions, with a condition definition of the trait being either empty or the current one.
jrfnl commentedon Nov 4, 2021
FYI: I've prepared all the necessary changes. I can start pulling them once I get a response to phpspec/prophecy-phpunit#34
aik099 commentedon Nov 9, 2021
@jrfnl , the phpspec/prophecy-phpunit#34 is merged now. You can send PR with autoloader now. Thank you.
jrfnl commentedon Nov 9, 2021
@aik I'm waiting for the follow-up PRs to be merged (step by step) - also see: phpspec/prophecy-phpunit#35 (comment)
jrfnl commentedon Nov 9, 2021
Alternatively, I could put those back in draft and pull them after the PR addressing this issue, but that's up to @stof. The currently open PRs are very minor small changes, so should be easy merges.
stof commentedon Nov 9, 2021
The currently opened PRs are not at all a blocker for that change anyway (bumping the min prophecy version does not impact the definition of the trait at all for instance). So you should be able to create the PR.
jrfnl commentedon Nov 9, 2021
I'll do some rebasing tomorrow, as, as I said before, the PRs make changes in the same files, so will be creating conflicts when pulled at the same time. Guess I'll just keep recreating commits and rebasing :-/
aik commentedon Nov 10, 2021
do not wait, I am the wrong "aik" :) @aik099 probably is.
jrfnl commentedon Nov 10, 2021
@aik Apologies and thanks for letting me know ❤️
jrfnl commentedon Nov 10, 2021
@stof @aik099 FYI: the PR has now been pulled - see phpspec/prophecy-phpunit#38
jrfnl commentedon Aug 24, 2022
I'm going to close this issue as this is not something which I intend to solve in the polyfills (forward compatibility vs backward compatibility). The PR to https://github.com/phpspec/prophecy-phpunit is (still) open and if it would be merged, I'll happily link to it from the readme of this package, but other than that, there is nothing to be done here.