[rspec-users] More on collection proxies
mlangenberg at gmail.com
Wed Jan 31 04:20:21 EST 2007
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
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
This is currently my spec and code: http://pastie.caboo.se/36900
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:
> 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
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users