[rspec-users] testing behaviour or testing code?

David Chelimsky dchelimsky at gmail.com
Fri Aug 24 17:00:06 EDT 2007


On 8/24/07, Pat Maddox <pergesu at gmail.com> wrote:
> On 8/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/24/07, Pat Maddox <pergesu at gmail.com> wrote:
> > > On 8/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > describe Widget, "class" do
> > > >   it "should provide a list of widgets sorted alphabetically" do
> > > >     Widget.should_receive(:find).with(:order => "name ASC")
> > > >     Widget.find_alphabetically
> > > >   end
> > > > end
> > > >
> > > > You're correct that the refactoring requires you to change the
> > > > object-level examples, and that is something that would be nice to
> > > > avoid. But also keep in mind that in java and C# people refactor
> > > > things like that all the time without batting an eye, because the
> > > > tools make it a one-step activity. Refactoring is changing the design
> > > > of your *system* without changing its behaviour. That doesn't really
> > > > fly all the way down to the object level 100% of the time.
> > > >
> > > > WDYT?
> > >
> > > I think that example is fine up until the model spec.  The
> > > find_alphabetically example should hit the db, imo.  With the current
> > > spec there's no way to know whether find_alphabetically actually works
> > > or not.  You're relying on knowledge of ActiveRecord here, trusting
> > > that the arguments to find are correct.
> >
> > Au contrare! This all starts with an Integration Test. I didn't post
> > the code but I did mention it.
>
> You're absolutely right, there should be an integration or acceptance
> test that exercises the behavior.  I would question then whether or
> not the example for find_alphabetically is (a) pulling its weight or
> (b) too brittle.
>
> (a) What value does the example provide?  It doesn't serve to document
> how find_alphabetically is used (usage doco is provided by good
> naming, and secondarily by the controller specs).  It doesn't give you
> any information that you couldn't get by looking at the
> implementation, because it duplicates the implementation exactly.  So
> the only real benefits of it is that you can see it when you visually
> scan the specs, and it shows up in the output when you generate spec
> docs.
>
> Those are real benefits, of course, which leads me to believe that the
> spec is just a bit brittle.  Knowing what exact arguments are passed
> to Widget.find doesn't add any value.  It makes the test more
> cluttered and brittle.  All we really care about is that a find is
> performed.  In that case, perhaps the example should be simply
>
> it "should provide a list of widgets sorted alphabetically" do
>   Widget.should_receive(:find)
>   Widget.find_alphabetically
> end
>
> WDYT?

The problem w/ that, for me, is that if I change that method for any
reason I won't know if I broke anything until I run the integration
tests. I'll trade off a bit of brittleness for rapid feedback. Not
always - but usually.

>
> > I play this both ways and haven't come to a preference, but I'm
> > leaning towards blocking database access from the rspec examples and
> > only allowing it my end to end tests (using Rails Integration Tests or
> > - soon - RSpec's new Story Runner).
>
> Will Story Runner give us all the same abilities as Rails ITs,
> obviating the need for test::unit altogether?

Yes. Just need to figure out how to wrap IT w/ Story Runner.

Cheers,
David

>
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list