rspec users - Jul 2010 - How are people speccing Rails 3 ActiveRecord queries?

Hi -- how are people speccing Rails 3 ActiveRecord queries?
At the minute I''m chaining a load of should_receive calls on mock
relation
objects, but can''t help thinking that there must be a more elegant way
of
going about it.
Is there a best practice for this, yet?
Cheers,
   Doug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100717/d807e31b/attachment.html>

El 17/07/2010, a las 17:37, doug livesey escribi?:
> Hi -- how are people speccing Rails 3 ActiveRecord queries?
> At the minute I''m chaining a load of should_receive calls on mock
relation
> objects, but can''t help thinking that there must be a more elegant
way of
> going about it.
> Is there a best practice for this, yet?
I''m pushing them down into the model where possible and testing the
model as a black box.

Cheers,
Wincent

On Jul 17, 2010, at 10:37 AM, doug livesey wrote:
> Hi -- how are people speccing Rails 3 ActiveRecord queries?
> At the minute I''m chaining a load of should_receive calls on mock
relation objects, but can''t help thinking that there must be a more
elegant way of going about it.
> Is there a best practice for this, yet?
For me, there is only one best practice: think. Everything else is a guideline
in some context.

That said, here are some of my guidelines, in context. YMMV.

My approach to spec''ing models is different from that for controllers
and views. In controller and view specs I prefer to stub out the data layer most
of the time because I don''t want the controller/view specs failing due
to things like validations, which are model concerns.

Spec''ing models is a different animal. I''ll still use stubs
where they make sense, but I''m perfectly happy using real objects and
interacting with the database when spec''ing behavior that is influenced
by the db and relationships between models.

I prefer to think of spec''ing behavior rather than spec''ing
query details. A simple example would be querying for the "active"
members of a group. We could say:

Member.should_receive(:where).with(:active => true)
Member.active

Or, we could say:

active_member = Factory(:member, :active => true)
inactive_member = Factory(:member, :active => false)
Member.active.should eq([active_member])

I, personally, find the latter more expressive, and we don''t have to
worry about the details of AR in the specs.

HTH,
David
> Cheers,
>    Doug.

Interesting.
I''ll give that a bash, too. I must admit, I tend to use the first
approach,
but the second seems a little more true to the spirit of testing.
I can imagine that it might get rather involved when setting up the database
for even half-way complex queries, though.
I''ll see how I get on with approach no. 2 for a while.
Thanks,
   Doug.

On 17 July 2010 17:11, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jul 17, 2010, at 10:37 AM, doug livesey wrote:
>
> > Hi -- how are people speccing Rails 3 ActiveRecord queries?
> > At the minute I''m chaining a load of should_receive calls on
mock
> relation objects, but can''t help thinking that there must be a
more elegant
> way of going about it.
> > Is there a best practice for this, yet?
>
> For me, there is only one best practice: think. Everything else is a
> guideline in some context.
>
> That said, here are some of my guidelines, in context. YMMV.
>
> My approach to spec''ing models is different from that for
controllers and
> views. In controller and view specs I prefer to stub out the data layer
most
> of the time because I don''t want the controller/view specs failing
due to
> things like validations, which are model concerns.
>
> Spec''ing models is a different animal. I''ll still use
stubs where they make
> sense, but I''m perfectly happy using real objects and interacting
with the
> database when spec''ing behavior that is influenced by the db and
> relationships between models.
>
> I prefer to think of spec''ing behavior rather than
spec''ing query details.
> A simple example would be querying for the "active" members of a
group. We
> could say:
>
> Member.should_receive(:where).with(:active => true)
> Member.active
>
> Or, we could say:
>
> active_member = Factory(:member, :active => true)
> inactive_member = Factory(:member, :active => false)
> Member.active.should eq([active_member])
>
> I, personally, find the latter more expressive, and we don''t have
to worry
> about the details of AR in the specs.
>
> HTH,
> David
>
> > Cheers,
> >    Doug.
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100717/7b7f0ef7/attachment.html>

On 17 Jul 2010, at 4:37 PM, doug livesey wrote:
> At the minute I''m chaining a load of should_receive calls on mock
relation objects

I''ve found this can cause pain in so many ways:

* Your tests end up coupled to the database structure (as that''s how
most associations are inferred)
* You''re at the mercy of the implementation of the association proxy
(I''ve found this more problematic with DataMapper, whose associations
haven''t always behaved quite how I expected them to...)
* You can easily end up with a lot of setup duplication

I''ve had enough pain from this that I now refuse to mock *any*
ActiveRecord (the library or the pattern) code.  It''s arguably a
violation of Don''t Mock Types You Don''t Own anyway.

HTH

Ash

-- 
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran