if the mocked class has a return type that does allow null, I get a null that goes further in the SUT, often delaying the test failure and making it really obscure to track it down
In both those cases, it's often the case of getting the mock's expectation slightly wrong, but I have no way of discovering it: I always have to widen it up until it matches and I get a green test, and then go back, making the expectation narrower as desired.
Is it possible to get the old behaviour back? Or to have a way to opt-out from this new behaviour? I understand that #441 was not considered a BC break because code as is had to be correct anyway, but while changing code this is really frustrating!
Jean85
commented
3 years ago
I was having some attrition while using Prophecy in my PHPUnit tests, and I track it down to mocks going further with unexpected calls.
I've opened https://github.com/phpspec/prophecy-phpunit/issues/27 thinking that the root issue was the migration from the old, deprecated PHPUnit integration to the new trait one, but I discovered that it wasn't, and instead it was https://github.com/phpspec/prophecy/issues/457 that, in 1.10, made this change.
That issue was closed by @ciaranmcnulty with:
... but I'm here to ask for a revert, or at least a switch to enable the old behavior back.
Why do I need this?
I would like to go back to mock failing hard and fast because writing (or altering) tests with this new behavior is extremely frustrating:
\TypeError(as pointed out by @stof in https://github.com/phpspec/prophecy/pull/441/files#r388191626)nullthat goes further in the SUT, often delaying the test failure and making it really obscure to track it downIn both those cases, it's often the case of getting the mock's expectation slightly wrong, but I have no way of discovering it: I always have to widen it up until it matches and I get a green test, and then go back, making the expectation narrower as desired.
Is it possible to get the old behaviour back? Or to have a way to opt-out from this new behaviour? I understand that #441 was not considered a BC break because code as is had to be correct anyway, but while changing code this is really frustrating!