rspec users - Apr 2009 - 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?
-- 
Posted via http://www.ruby-forum.com/.

Fernando Perez 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.
-- 
Posted via http://www.ruby-forum.com/.

On 15 Apr 2009, at 15:30, Phlip wrote:
> Fernando Perez 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.
It doesn''t slow tests down!? Are you sure?


Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

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

On Wed, Apr 15, 2009 at 7:19 AM, Fernando Perez <lists at ruby-forum.com>
wrote:
> 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?
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>