On Thu, May 26, 2011 at 12:10 AM, Justin Ko <jko...@gmail.com> wrote:
> > > On Wed, May 25, 2011 at 6:11 PM, Ken Egervari <ken.egerv...@gmail.com>wrote: > >> On Wed, May 25, 2011 at 5:34 PM, David Chelimsky <dchelim...@gmail.com>wrote: >> >>> On May 25, 2011, at 2:00 PM, Ken Egervari wrote: >>> >>> I am using factory_girl, and I have discovered that it is chiefly >>> responsible for making my tests run slow. >>> >>> I have posted a question about this on Stack Overflow: >>> >>> >>> http://stackoverflow.com/questions/6128476/how-can-i-get-factory-girl-to-never-hit-the-database-if-i-am-calling-factory-buil >>> >>> Anyway, I was curious what you guys use to create Factories? >>> >>> 1. Do you put up with Factory_girl? >>> 2. Did you configure Factory_girl differently to make it run faster? >>> 3. Do you use something else? May I ask what? >>> >>> Thanks! >>> >>> Ken >>> >>> >>> The factory girl docs on >>> http://rubydoc.info/gems/factory_girl/1.3.3/frames offer a few options. >>> Look for the :default_strategy option and the :factory option on >>> association. >>> >>> HTH, >>> David >>> >> >> Yeah, :default_strategy helps somewhat... but not really. I have done a >> lot of tests/profiling and even if I resorted to Factory.build() for >> everything, it ends up being much slower than just making the objects >> myself. >> >> I won't get rid of factory_girl outright - it's a good little tool to have >> when you need to create a mini-database, which happens quite a bit in >> practice (testing scopes, and so on). >> >> But I think a good rule of thumb is not use it like a basic defacto >> object-instantiation tool. Maybe that's my bad, but articles, screencasts, >> etc. actually tell people to do this - and given it's performance >> implications, I believe that should NOT be a best practice. >> >> For me, I will use normal Rails/Ruby objects until they become too >> cumbersome to build in order to satisfy validations or when I need to put >> something in the database because that is part of the test. Otherwise, it's >> better to work with pure, transient objects that you create yourself. >> >> I have literally got my entire test suite to run in 25 seconds when it >> used to run in over 90 before. That's quite a big jump - several times >> faster than swapping to an in-memory database. >> >> I only wish I knew this when I started my Rails app and just following >> what I believe to be the "true" best practice from the start. I guess I >> gotta live and learn. I hope others don't fall into the same pitfall like I >> did though. >> >> Ken >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > Again, please bring it up with the factory_girl authors. I'm sure they > would like to know there might be some performance issues. Thanks. > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > Actually, I did bring it to their attention and just hear a response. It turns out someone pointed this out back in June of 2010. Not a good sign :( They already knew though.
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
