[rspec-users] Where is current_user?

David Chelimsky dchelimsky at gmail.com
Wed Oct 22 08:05:34 EDT 2008

On Tue, Oct 21, 2008 at 9:39 PM, Harry Bishop <lists at ruby-forum.com> wrote:
> Thanks David,
> Your method works well and rspec succeeds now.
> Is the preferred way of using code with rspec to not rely on instance
> variables set in a parent during execution but to rely on the method
> only construct to be able to interact?
> I see the way this works for the outline you provided.  I am wondering
> what the implications are with respect to writing ruby code with the
> assumption parent instance variables will be inherited by children.  The
> approach you are providing would indicate that an attr_read method is
> preferred so that the retrieve method can be stubbed since the instance
> variable doesn't get set when tested.
> Is this a general rule of practice with rspec?  As a beginner I'm trying
> to get the larger picture here and appreciate your insight with this.

This is more of a design thing than an rspec thing. While hierarchies
can be useful for sharing behaviour and the concept of class, sharing
state up and down a hierarchy can be quite confusing and error prone.

* Variable names are far more likely to change than method names. The
implication is that you're more likely to get bitten because somebody
else changed an instance variable name in another class in the
hierarchy (above OR below) than if a method name changes. People just
take greater care when changing method names.
* To understand that an instance variable is shared up and down a
hierarchy I have to look at the code, whereas to understand that an
instance method is overridden, I simply need look at the instance
methods, which I easily do in irb, or looking at rdoc.
* Overriding methods goes in one direction in a hierarchy, while
resetting instance variables can go in either direction and lead to
some nasty bugs.

And, of course, relying on methods instead of variables also makes it
easier to mock and stub :) For me, that is very important.


> HR

More information about the rspec-users mailing list