[rspec-users] testing behaviour or testing code?

Pat Maddox pergesu at gmail.com
Fri Aug 24 14:20:15 EDT 2007

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

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


> 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?


More information about the rspec-users mailing list