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.
HR
On Tue, Oct 21, 2008 at 9:39 PM, Harry B. [email protected]
wrote:
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.
FWIW,
David
David C. wrote:
On Tue, Oct 21, 2008 at 9:39 PM, Harry B. [email protected]
wrote:
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.
FWIW,
David
David,
I agree with this philosophy. Sometimes in using a language it isn’t
always clear which approach will be a better payoff. I appreciate your
advice here.
HR