Forum: RSpec How to test/spec an ActiveRecord find that uses :include

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Fernando P. (Guest)
on 2009-04-15 18:19
Hi,

I was refactoring my model specs so that they don't hit the database,
but how to handle a custom find that uses :joins or :include with some
important :conditions? I can't see a way to not hit the database.

Should that spec actually belong to an integration spec?
Phlip (Guest)
on 2009-04-15 19:11
(Received via mailing list)
Fernando P. wrote:

> I was refactoring my model specs so that they don't hit the database,
> but how to handle a custom find that uses :joins or :include with some
> important :conditions? I can't see a way to not hit the database.

What's wrong with hitting the database?

When high-end consultants like Mike Feathers tell you not to hit the
database,
what they are really saying is that programmers using big iron languages
like
C++ or Java should start decoupling by any means necessary. It's just a
mind-game.

At the other extreme, systems like Rails and its test fixtures have
illustrated
how you can leverage the database for a pool of stub objects. It doesn't
lead to
bad design, or slow tests down.

--
   Phlip
Fernando P. (Guest)
on 2009-04-15 19:14
> What's wrong with hitting the database?
Actually it slows tests down like hell. I was able to ÷10 my testing
time by not hitting the DB as much as I used to.

But I think that hitting DB for such case is acceptable.
Matt W. (Guest)
on 2009-04-15 19:24
(Received via mailing list)
On 15 Apr 2009, at 15:30, Phlip wrote:

> database, what they are really saying is that programmers using big
> iron languages like C++ or Java should start decoupling by any means
> necessary. It's just a mind-game.
>
> At the other extreme, systems like Rails and its test fixtures have
> illustrated how you can leverage the database for a pool of stub
> objects. It doesn't lead to bad design, or slow tests down.

It doesn't slow tests down!? Are you sure?


Matt W.
http://blog.mattwynne.net
http://www.songkick.com
Pat M. (Guest)
on 2009-04-15 20:25
(Received via mailing list)
You have to hit the db here to make sure that it works.  Can't isolate
all the time, especially when building database-centric apps ;)

As for testing it, the easiest way I know of to test the association
was included is to check #loaded? on the proxy.

h = Harbor.first
h.marinas.should be_loaded

That works right out of the box and is usually enough to make you
confident that the find was done with an include.  You can also hook
into AR.find/execute and count the number of queries and verify that
there's only one.

Pat
This topic is locked and can not be replied to.