[rspec-users] do I use mocking (vs fixtures) for methods that produce results based on non-trivial SQL queries
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
>>>> figure), then 5 will take 1 sec, at 1000 over 3 minutes, and at
>>>> over 6
>>>> minutes. This is starting to get into "time for a
>>>> 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
>>>> 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
>>> 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
>>>> know if
>>>> you are interested and I'll make the project publicly viewable on
> Thats cool. I was actually talking to our DBA about the possibility
> 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
> 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
>> a gander (although it most certainly is still a work in progress):
> Awesome. I'll for sure take a look at this.
>> rspec-users mailing list
>> rspec-users at rubyforge.org
> 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
> results. That way I can have a faster functional spec test that
> 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?"
More information about the rspec-users