Skip to content
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

Closed
DanSTurner opened this issue Nov 19, 2013 · 2 comments
Closed

expect#with doesn't say what was returned #167

DanSTurner opened this issue Nov 19, 2013 · 2 comments
Assignees

Comments

@DanSTurner
Copy link

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:

  def test_provide_answer
    @CLI.expects(:gets).returns("1 + 1")
    @CLI.expects(:puts).with("2.0")
    @CLI.evaluate_expression
  end

code:

  def evaluate_expression
    puts eval(self.get_expression)
  end

terminal output:

  1) Failure:
CLITest#test_provide_answer [/Users/dansturner/projects/calculator/lib/cli.rb:13]:
unexpected invocation: #<CLI:0x7faa1a0c0168>.puts(2.0)
unsatisfied expectations:
- expected exactly once, not yet invoked: #<CLI:0x7faa1a0c0168>.puts('2.0')
satisfied expectations:
- expected exactly once, invoked once: #<CLI:0x7faa1a0c0168>.gets(any_parameters)

More useful behavior would be something like:

- expected exactly once, not invoked with correct parameter: #<CLI:0x7faa1a0c0168>.puts('2.0')
  was invoked 1 time, <CLI:0x7faa1a0c0168>.puts(2.0)

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.

@floehopper
Copy link
Member

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.

@floehopper
Copy link
Member

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:

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.

But this is not true. In your example, the description of the unexpected invocation does not have quotes around the 2.0 in #<CLI:0x7faa1a0c0168>.puts(2.0); whereas the description of the unsatisfied expectation does have quotes around the '2.0' in #<CLI:0x7faa1a0c0168>.puts('2.0'). I understand that this is not obvious at first glance, but if you read the descriptions carefully it is possible to work out what's going on.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants