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

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?

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

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.

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 :wink:

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

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs