[rspec-users] do I use mocking (vs fixtures) for methods that produce results based on non-trivial SQL queries

Ben Mabey ben at benmabey.com
Fri Sep 5 11:40:47 EDT 2008

Scott Taylor wrote:
> On Sep 5, 2008, at 10:55 AM, Pat Maddox wrote:
>>> time.  Just do the math: If one database test takes 0.2 sec (a
>>> realistic
>>> figure), then 5 will take 1 sec, at 1000 over 3 minutes, and at 2000
>>> over 6
>>> minutes.  This is starting to get into "time for a
>>> coffee/cigarette/juggling
>>> what have you" breaks.  So - either you end up very hyped up on
>>> coffee not
>>> doing much work, or you don't run your test suite very often, which
>>> leads to
>>> legitimate bugs which can be solved. (At one point I had actually
>>> deployed
>>> code into production which had a serious bug.  This all could have been
>>> avoided because the test suite *was failing*, but I had gotten into the
>>> habit of not running it because it was too expensive).
>> There's a couple things you can do to help with this:
>> * Split slow tests into another dir and run them separately from your
>> fast suite.  Keep rspactor on your fast suite and run the slow tests
>> before checkin
>> * Use a CI server
> Yes, most certainly.  But the db tests •still* aren't cheap, meaning
> you'll need to wait for the CI server to run them there is a failure,
> or wait before checking in.
> Also - have you found a CI server that is working with git?

On github you can find forks of cc.rb with added git support.  I have
been using it like a charm for months.
>>> I've been working hard on solving this issue by building a SQL
>>> parser in
>>> treetop, and hope anyone who is interested will join me (just let me
>>> know if
>>> you are interested and I'll make the project publicly viewable on
>>> github).
Thats cool.  I was actually talking to our DBA about the possibility of
this the other day.  I think for the simple cases something like this
would be great.  I have been using the nulldb adapter will a lot of
success recently but there are a few spots where just simple insert and
select statements would go a long ways.

>> http://github.com/nkallen/arel/tree/master might also be interesting
>> to you.
> Hmm..Well, that's interesting, although I think that project, like so
> many others, is *generating* SQL, not parsing it, correct?
> I've made my sql parser public, and here is is if anyone wants to take
> a gander (although it most certainly is still a work in progress):
> http://github.com/smtlaissezfaire/guillotine/tree/master

Awesome.  I'll for sure take a look at this.
> Scott
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

To answer the original poster's question.. I tend to isolate my SQL
calls to single methods and don't allow those methods to operate on the
results.  That way I can have a faster functional spec test that method
individually with a smaller data set in the DB.  I will then stub out
the calls to that object#method in my specs where the interesting
business logic uses that data to produce results.  I then have an
interaction test in form of a story that does more complex setup and
testing of both methods and the DB in unison.  My main motivation for
this separation is for speed of my specs that are for my business
logic.  If what I have said doesn't make sense I can given an example of
what I mean.


More information about the rspec-users mailing list