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

Testing RSpec
1

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?

2

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

3

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.

4

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

5

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