On Dec 17, 2007 1:08 PM, David Chelimsky <[EMAIL PROTECTED]> wrote:
>
> On Dec 17, 2007 3:02 PM, Brian Takita <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 17, 2007 11:02 AM, Scott Taylor <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > On Dec 17, 2007, at 3:25 AM, Brian Takita wrote:
> > >
> > > > On Dec 16, 2007 7:43 PM, Scott Taylor
> > > > <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> Francis and Pat probably know my thoughts on this, already, but as
> > > >> far as I can see it, mocks (at least the message based ones) are
> > > >> popular for one reason in the rails / active-record world:
> > > >>
> > > >> Speed. Mocks are extremely fast. I don't think it's uncommon for
> > > >> those who write specs for rails projects to have a full test suite
> > > >> running in under 20 seconds if they are mocking all dependencies.
> > > >> Primarily, this means using mocks for all associations on a Rails
> > > >> model, and using only mocks for controller specs.
> > > > My experience with AR is that AR itself (mainly object instantiation)
> > > > is slow, not the queries.
> > > > Mocking the queries did not result in a worthwhile test run time
> > > > savings.
> > > > Rails creates lots of objects, which causes lots of slowness. Its
> > > > death by a thousand cuts.
> > > >
> > > > I guess one could mock out the entire AR object, but I'm not convinced
> > > > that it would result in large performance benefits in many cases.
> > > > I've tried doing this a couple of times and did not save much time at
> > > > all. Of course, this was done in view examples on a project that uses
> > > > Markaby (which is slow).
> > > >
> > > > Whatever you do, I recommend taking performance metrics of your suite
> > > > as you try to diagnose the slowness. The results will probably be
> > > > surprising.
> > >
> > > Certainly. A lesson in premature optimization. Although, I did
> > > notice that
> > > my test suite took about half the time with an in-memory sqllite3
> > > database,
> > > so I would find it hard to believe that most of the time is spent in
> > > object
> > > creation - but...off to do some benchmarking.
> > True. I also did some custom fixture optimizations. For some reason,
> > instantiating a Fixture object instance is very slow. I've rigged it
> > so there is only one instance of a Fixture object for each table for
> > the entire process.
> > Of course this would break fixture scenarios.
>
> Did you do that in rspec? Or in your own project?
My own project.
I overrode Test::Unit::TestCase @@already_loaded_fixtures with a shim.
>
>
> >
> > I've had around 20-30% increases using in memory sqllite, about 1 year
> > ago. I havn't tried it since.
> >
> > >
> > > Scott
> > >
> > >
> > > _______________________________________________
> > > rspec-users mailing list
> > > rspec-users@rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
