-
Notifications
You must be signed in to change notification settings - Fork 38
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
Add support for Phpunit 10 #45
Conversation
It seems that the only point where a failure is triggered in the whole PHPUnit 10 codebase is here: https://github.com/sebastianbergmann/phpunit/blob/250b8d3e9fc5c27a4947291a6bec720eba015f07/src/Framework/TestCase.php#L639-L646 It's a catch block that catches either The first one depends on ini settings to work as expected, and the latter is declared The exception that is triggering the error in this case has this stack trace:
so, the only way that I can think of to fix this is:
|
Ok, that doesn't seem feesible: Any other pointer? |
AFAICT Prophecy is using PHPUnit 9 for |
@icanhazstring I don't understand your comment. I don't see how the dev requirement of prophecy is related to the discussion happening here. @Jean85 As discussed in the previous PR on that topic, I think we are missing a PHPUnit extension point here to be able to implement that feature. |
I don't fully agree: the extension point is probably already there, and it's either:
The impediment here is in Prophecy, that is not easily extendable/decorable at this point. |
@Jean85 To me, the issue is that PHPUnit does not allow to easily convert external assertion failures to a PHPUnit assertion. Forcing Prophecy to directly throw an AssertionFailedError exception would require to couple Prophecy itself to PHPUnit, which is a no-go (it is also a no-go for most external assertions libraries btw. Drupal had the same issue about Mink assertions marking tests as errored instead of failed).
Note that in the past, |
@stof sorry, misunderstook how prophecy is integrated into phpunit. As part of the change needed. |
@icanhazstring From what I saw until now (I might be wrong as I haven't spent a long time on that yet), I don't think the new event system would help us here to mark a test catching a PredictionException as failed instead of errored. AFAICT, listeners are not allowed to change the test status, they can only read it. |
Same for me. Haven't digged deeper into that. But would make sense. Maybe someone who wrote that could have more input on that. Will ask around a little. |
I'm doing quite some work with PHPUnit events, and I can try to weigh in a little.
You don't change test status with a listener, but you can try to dispatch an event (using
Is this enough? |
@Jean85 but those catching are done in |
Understood. Well, I fear that we'll need @sebastianbergmann to weigh in and suggest us the best course of action. Sebastian, a TL;DR for you: in Prophecy, when a spy fails its prediction ( With PHPUnit 10 this is gone, and we can't think of a way to fix this. |
Are you asking for a marker interface that is provided by PHPUnit and when an exception that implements this marker interface is raised during a test then that exception is to be treated as a failure? |
Another exception that can be used by libraries to mark a test as failed could also work I suppose. |
I have created sebastianbergmann/phpunit#5201 to track this. |
Thanks Sebastian! |
@sebastianbergmann ideally, it would be great if it was not a marker interface coming from PHPUnit, as that would mean that Prophecy would have to depend on PHPUnit just to make An alternative way would be to implement that through an attribute instead of a marker exception (as such attribute does not introduce a hard coupling). But then, it would still be great to support adding the attribute on an interface or a parent class instead of having to put it directly on the class being triggered. Another alternative is to make |
This would encourage bad practices if the recommended way is that each library doing such assertions (Prophecy, but also Mockery, Mink, etc...) would re-declare the marker interface, because it means that PHPUnit would never be able to change that marker interface anymore without breaking the ecosystem badly (as those re-declarations would not automatically be in sync with PHPUnit). |
Ah, now I understand. Thanks! |
To be fair, I was thinking about a conditional redeclaration. Being a marker interface, it would be needed to be empty, any change would be a BC... Still, registering marker interfaces or classes is a better approach 👍 |
The build currently fails because of an authentication failure. Can you retry? |
I cannot. Also, the failure comes from the fact that we need to install phpspec/prophecy#585, and stems from ramsey/composer-install#241. The short term solution is to have a GitHub token added to the CI to pull the Prophecy fork in. Or we need to wait for that to be merged. |
Hi. Do you continue this feature? |
We're in a deadlock of PR to be merged... this one, phpspec/prophecy#585 and phpspec/phpspec#1444 :( |
FYI: I contacted @ciaranmcnulty and some of blocking PRs got merged, so there are only two more steps to provide PHPUnit 10 support 🙂 (this and phpspec/phpspec#1444). It needs to be verified, though. |
25f1af0
to
6995d73
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FINALLY!!! It's green and it's working!
We may have to wait for phpspec/prophecy#585 to be tagged, but it's ready!
.github/workflows/ci.yml
Outdated
include: | ||
- name: with PHPUnit 10.1 | ||
php: '8.1' | ||
phpunit: '10.1.x-dev' # change this with ^10.1 when released |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a specific CI job to test against PHPUnit 10
PHPUnit 10.1 is released, this PR is ready to go! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also fix the conflicts
a8c51be
to
14b4960
Compare
Was this the last blocker for PHPUnit 10 compatibility? If so, is it possible to create a release including this PR? |
This is a rework of #41, after #43.
As @stof noted there, now the CI is highlighting that, under PHPUnit 10, Prophecy is behaving badly, and rendering an error instead of a failure when a Spy detects an unmet expectation.Apart from that, this PR is complete; I'll try to delve a bit, to understand if that has to be fixed here or on Prophecy.PHPUnit 10.1 is now released, including sebastianbergmann/phpunit#5201, and this PR is ready!