prophecy: Callcenter returns null on non registered method call
Hello,
First I do not often submit issues, so please accept my apologies if it is far from perfect. This comment https://github.com/phpspec/prophecy/pull/441/files#r388191626 is perfectly true (as often with Stof) and thus creates an exception with an imprecise message.
Where I would like to see that there was no configured methodCall for these arguments with the list of provided arguments, I have a message about type mismatch. This means to correct the error I have to look at the arguments with a debugger for instance.
I wonder if it is good to authorise a call that must return a value to fail later in case of shouldHaveBeenCalled() because it is not the job of prophecy to know/guess what to return.
I think an option is to return the good type thanks to reflection. Another option would be to check if the type of return is not void and throw the exception immediately which would mean users could not expect a shouldHaveBeenCalled to work for function with a return value without defining the correct return value themselves. There may be a lot of other better options but I only thought of these for now.
Could you please tell me where I made mistakes in my understandings. And if I’m correct about the problem how should we proceed to make this better?
PS : @everzet I’m a regular user of Prophecy and I want to thank you for this piece of software.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 2
- Comments: 15 (13 by maintainers)
The less disruptive way is a major version, so that projects have to opt-in for the behavior change. #441 was about allowing to write tests in a way that was not supported before, and which is basically incompatible with any codebase not allowing
nulleverywhere. Projects relying on that new way will need to be updated. All other projects will get back a much saner failure mode for broken code.@ciaranmcnulty the current behavior is bad for anyone not using spies. Before #441, the
UnexpectedCallExceptionhad a stack trace pointing where the unexpected call happened, making it dead easy to fix it. After #441, you have no helpful info. I would say that Prophecy should have a way to opt-in into the spying rather than opting out (as it cannot guess that spying assertions will be used later). Either that, or it should still require you to stub any method on which you want to spy so that their behavior is defined (which is basically what happened before #441).