On Monday, February 11, 2013 4:05:12 PM UTC-8, Myron Marston wrote:

> I consider the use of `should_receive` with a return value to be a code 
> smell since I generally care about command/query separation.
>

Combining should_receive with a return value is not in any way related to 
command/query separation. You could replace the mock with a stub or (if the 
return value isn't being used by the code under test) remove the return 
value, and the test would be equivalent, and would still violate (or not 
violate) command/query separation just as much as before.

In fact, in the most recent relevant interaction I had with a fellow 
developer about this, he had mocked SomeModule.display_name (a method with *no 
side-effects*), and provided a return value. He never tested that the 
return value was used correctly, because he felt it would be too cumbersome 
to check that a CSV file was created with the right data. Hence the mock 
was some kind of (basically meaningless) reassurance to him.

> If using `should_receive(:foo).and_return(value)` bothers you that much, 
then feel free not to use it

It's not about some subjective distaste for it. It's a dishonest statement 
that the method has some side-effect that must be triggered. Indeed, if my 
friend had found himself unable to return a value from a mock, it would 
have encouraged him to make a realization about the nature of his test.

you may want to specify that a particular message is sent to the 
> collaborator only once, and `should_receive(:message).once` is a fine way 
> to do that.
>

This is semantically different than a should_receive; specifically, it's a 
"should *not* receive more than once". You could argue that the semantic 
clarity isn't valuable enough to warrant something like 
double.should_cache(:foo), but I'd certainly welcome it as part of a change 
to make it impossible to return values from mocks.
 

> I think you're instincts that it's often not needed (and that confusing 
> stubs with mocks is bad) are correct.  But there are still cases where it's 
> useful, and RSpec provides it.
>

I speculate that the *only* case in which it's useful is when a value 
should be cached, and therefore need not be called more than once. In which 
case something like the should_cache method would solve the problem.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msg/rspec/-/RETWugDQmf4J.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to