[rspec-users] More on collection proxies

David Chelimsky dchelimsky at gmail.com
Sat Jan 27 10:03:18 EST 2007

On 1/27/07, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> Why shouldn't private methods be tested? I use Object#send all the
> time to test private methods, otherwise I've got the idea the step to
> implement the spec is too big, for example look at the specs of my
> SMSer project (http://pastie.caboo.se/36044).

There is a school of thought that suggests that if you need to test
privates that you're probably doing too much in the one class and you
should consider breaking things out. Admittedly, this school of
thought comes from static languages in which you have to go through
crazy and error prone hoops in order to test privates. Since Ruby
makes it so simple, it seems less harmful and risky.

It should, however, be at least a red flag about your design. It
should make you ask "why am I testing privates?".

The questions I have are:

What is the impact of extracting the error code?
Does doing so change some other behaviour?
Isn't it enough to spec "should raise an exception if the webservice
returned an error"?

Getting back to my earlier statement about breaking things out, you
*could* (and I likely would) choose to make a new class SmsResponse
that gets initialized with the xml response text and exposes :code and
:message. Then you could eliminate the last two specs in your example
and have a separate spec just for this new class:

The cost of this is an extra class. The benefit is good separation of
concerns (parsing XML vs processing a logical response).

Similarly, the product of :create_post_data must go somewhere, right?
What effect does that have on behavior? If it simply gets stored, then
you can mock out the storage to make sure it gets stored correctly. If
it changes the behaviour of the SMSer, then you can have examples that
show the different behaviours.

All of this said, these principles exist because people have
experienced pain from doing things. You may be absolutely fine w/ what
you have. The risk that you run is that business rules about SMSer and
the XML schema for the response change independently, and then you
have two reasons to change the same class (violation of the Single
Responsibility Principle), making it more prone to ripple effects.

An other thing to consider is whether there are other parts of your
system that have to parse the same XML. If that is the case, then its
definitely to your benefit to break out an SmsResponse class.



> On 1/26/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> > David Chelimsky wrote:
> > >> Jay Levitt wrote:
> > >>
> > >> validates_presence_of is a bad example, because the two methods are
> > >> practically interchangeable.  But consider a validation that uses a
> > >> regex to verify a legal IP address.  Do you want your specs to repeat
> > >> the regex, or do you want to test various legal and illegal IP-address
> > >> strings and see what breaks?  To me, it's the second one that's actually
> > >> testing the behavior of the application.
> > >
> > > Another view would be that the Regexp is a separate component that
> > > you'd want to test separately from the use of that component. So the
> > > test that your model validates_format_of using a Regexp uses the right
> > > one and then have other tests just for that Regexp.
> >
> > I'd counter that the Regexp is essentially a private method that
> > shouldn't be tested.  It's never directly used by the outside world;
> > only the validation is.
> >
> > Jay
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list