From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-08-21T18:26:43+09:00
Subject: [ruby-talk:4522] Re: RubyUnit and encapsulation.

On 18 Aug 2000, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
> 
> > My_class's instance variables are not all "attr :<name>" type variables,
> > so some can only be accessed from inside the class.  That is fine, it is
> > what OO is all about.
> 
> Encapsulation is good.

Agreed.
> 
> > It seems like 1 is the only sensible way to do this, and "If the
> > errors don't localise the bugs, then Tough!". Is such a question too
> > case-specific to have any useful general answer(s)?
> 
> I wouldn't put it so negatively. Instead say: all that matters about
> my class is its external interface. Therefore, the first and most
> basic thing I must test is that interface. Do that.

OK.
> 
> Then form an opinion. Are those tests revealing a multitude of [bugs...]
> then you have a couple of options when it comes to increasing the
> scope of your testing:
> 
> 1. Produce a subclass of your main class with accessors for the
>    internal state and private functions (remember, you can override
>    scope in a subclass in Ruby).

That is a nice idea. Thank you.
> 
> 2. Refactor your main class. If you really are finding these kind of
>    errors, then perhaps your main class is too complex. Maybe it should 
>    be refactored, allowing you to write tests for the refactored-out
>    helper classes.

I just bought Fowler, et al, "Refactoring", so I can learn more about
that.
> 
> However, I suspect that if you take the "don't do it until you need
> it" approach, you'll find that you won't need it. In any case, I would

I'm fairly sure it works as a whole because my test examples seem to do
what I want when I use the class, so this is probably true.  I was trying
for more rigour.  Those tests are not RubyUnit tests yet.
 
> personally fight against breaking encapsulation just so I could
> test. Instead, I'd treat it as being a symptom of some deeper issue.

I was thinking along those lines. Maybe when I have read the book I 
will know what questions to ask about the deepr issues.  Which is why
this next question is so poorly put:
> 
> > The implication seems to be that I should redesign my class, but in
> > what way(s)?  My class currently holds arrays, hashes, and booleans
> > in a unified whole. Most of the methos setup the correct values in
> > these as files are processed.
> 
> Not knowing the details, it's difficult to be specific, but perhaps an 
> initial refactoring might involve separating the data storage (the
> interacting hashes, arrays etc) from the file reading.

Maybe omething like the creation of a syntax tree for an intermediate
step, as this is a sort of parser.  OK, I will see what I can come up
with. 
> 
> 
> Regards
> 
> 
> Dave
> 
> 
	Thank you,
	Hugh
	hgs@dmu.ac.uk