-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
expect#with doesn't say what was returned #167
Comments
Thanks for taking the trouble to write this up. I'm really busy at the moment, but I'll try to have a look at it as soon as I can. |
Hi Dan. I'm sorry not to have replied sooner. I have to admit, I'm a little bit confused by some of what you've said. You seem to be talking about two or three different things. One thing you said was:
But this is not true. In your example, the description of the unexpected invocation does not have quotes around the The "more useful behaviour" that you describe sounds simple in your example, but I think it's difficult to generalise it into all the possible combinations of things that might happen. One thing we could do when an unexpected invocation occurs is to list all the other expectations for that method alongside the the unexpected invocation. I've added a new issue to capture this idea - #177. Also I'm not sure this is what you are suggesting, but it would be possible to display all the actual invocations recorded against both unsatisfied & satisfied expectations, including the parameter values passed into the method and the return value generated by the expectation. I've added a new issue to capture this idea - #178. Something else we could do would be to display the expectations in a way that is more similar to how they are defined and include things like definition of return values. I've added a new issue to capture this idea - #179. I think the 3 feature requests above capture all the ideas within this issue, so I'm going to close this one. I hope that's ok with you. Please let me know if you think I've missed something. I'm not guaranteeing that these features will be implemented, but I think they are all interesting ideas that could improve Mocha. Pull requests are always welcome! 😉 Cheers, James. |
When a with expectation was not met it doesn't indicate the actual result. Details which would be useful would be if the method was called, how many times and what the parameters were.
For example:
test:
code:
terminal output:
More useful behavior would be something like:
This would be more useful because the original description of the unsatisfied expectation doesn't indicate that the puts was called with a number instead of a string which makes it trickier to debug.
This would make a great project even better.
The text was updated successfully, but these errors were encountered: