[rspec-users] Keeping unit tests from hitting the DB

Pat Maddox pergesu at gmail.com
Fri Aug 24 00:48:22 EDT 2007

On 8/23/07, Jim Deville <james.deville at gmail.com> wrote:
> >>>>
> > As far as model specs go...I've been toying with the idea of splitting
> > up non-db-reliant behavior specs from the specs that do require the
> > database.  When you want to specify behavior you can just stub out the
> > columns (because AR does try to hit the db to find the column info).
> > Obviously for things where you need to hit the db, such as custom
> > finders and such, you should use a real db.  Kent Beck proposed
> > writing a mock db interface that expects SQL queries but I thoroughly
> > hate that idea.
> >
> I'm wondering why custom finders need to hit the database? Mocking
> out the columns method (as suggested by the articles) should work
> just as well for custom finders as it would for AR finders.   Am I
> missing something?
> Jim

If I've got something like

def find_recent(limit = 5)
  find :all, :order => "created_at DESC", :limit => limit

I think it's better to just create 6 records and make sure it returns
the proper 5.  Then write another spec that only gets 3.

I suppose you could use a mock db that ensures that the SQL is
valid...but that seems brittle.  Also at some point you have to ensure
that the generated SQL actually works (by running it).  Might as well
do that in the spec itself.  Also that's a better way because the
behavior you want in this case is for it to find the proper records,
not to generate some particular SQL string.


More information about the rspec-users mailing list