[rspec-users] More on collection proxies

David Chelimsky dchelimsky at gmail.com
Wed Jan 31 08:07:26 EST 2007


On 1/31/07, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> David, thanks for your reply. I've made some changes to my specs and
> code, but I'm still not really sure where I should move the private
> 'create_post_data' method, should there be a seperate class for that
> method to?
> Same question for the 'send_http_post_request' method, although I
> think it's a good idea to put that method in a different class /
> context, allowing me to write a sample webservice to assert the http
> post.
> This is currently my spec and code: http://pastie.caboo.se/36900

This line is the perfect place to introduce a new class:

@sms_response = SMSResponse.new(send_http_post_request(SERVICE_URI,
create_post_data(dutch_mobile, msg)))

How about this:

@sms_response = SMSRequest.new(dutch_mobile, msg).post(SERVICE_URI)

and then moving the creation of the SMSResponse to the SMSRequest?
This applies TDA and separates things nicely.

WDYT?

>
> - Matthijs
>
> On 1/27/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > 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:
> > http://pastie.caboo.se/36071
> >
> > 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.
> >
> > WDYT?
> >
> > David
> >
> >
> >
> >
> > >
> > > 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
> > >
> > _______________________________________________
> > 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