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

Scott Taylor mailing_lists at railsnewbie.com
Fri Sep 5 12:23:23 EDT 2008


On Sep 5, 2008, at 11:40 AM, Ben Mabey wrote:

> 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.


Doesn't this violate the rule of "never stub the method under test?"

Scott



More information about the rspec-users mailing list