[LRUG] Making your tests run fast enough?

Tue Jan 24 02:58:20 PST 2012

If you can get parallel tests working it makes a massive difference if you've got a decent multicore processor. I saw a 4x increase with a 6 core processor, and I'm fairly sure I could improve that by optimising a few really large test classes.

On Tuesday, 24 January 2012 at 10:55, Ian Leitch wrote:

> In a nutshell, if you're loading the Rails environment.. you're always
> going to have a startup cost (unless you use Spork or something but
> they also have their downsides).
> 
> Here's a few things you can try though:
> 
> 1) I've experimented with ramdisks before but never seen much of an
> improvement. I suspect that in a test environment IO from the database
> isn't a limiting factor, its the descending of layers from app, AR, db
> query parser, planner etc that carries the cost. As previously
> mentioned, avoid hitting the database wherever possible.
> 
> 2) Profile your tests. perftools.rb is great. You'll probably see the
> GC near the top somewhere, if you're using REE or 1.9.3 you can tune
> the GC for a nice improvement. You need to allocate enough memory
> straight off so that at least your environment can be loaded without
> the GC causing another bucket to be allocated.
> 
> Also keep an eye out for other suspicious things - ActiveRecord
> callbacks building massess of objects that aren't needed for your
> specific test are a good candidate for stubbing.
> 
> 3) Prune your Gemfile for any cruft.
> 
> 4) Use capybara-webkit for your Cucumber tests if you need Javascript.
> 
> 5) A long-term goal is to embrace the separation of Rails and your
> app. The key point in Corey's talk is that avoiding Rails isn't so
> much a technique to improve test speed, but more of a fundamental of
> rule of developing with Rails. Rails is a dependency of your app,
> wherever possible extract your domain logic into modules and classes
> that live inside lib/. Your models should contain nothing more than
> simple methods that abstract the specifics of interacting with AR.
> 
> This is the biggest win for your unit tests. Not only will they be
> much simpler to write (boundaries are easily identified and stubbed),
> but fast! The vast majority of code in my app lives in lib/ and it
> takes ~0.85s to run ~500 examples. This also includes my controllers
> which use an ActionController test double.
> 
> 6) Although this wont help for single test runs. Parallelization can
> be a big win for CI.
> - Hydra is a popular one but it uses a single database which results
> in deadlocks.
> - parallel_tests uses separate databases, but I found it a pain to get going.
> - I wrote my own a while back (https://github.com/envato/swarm). It
> also uses separate databases, though I'm afraid there's no
> documentation (its on my TODO!).
> 
> 7) Get a faster machine ;)
> 
> Hope some of those points help.
> 
> Cheers
> Ian
> 
> On 24 January 2012 10:07, Mark Burns <markthedeveloper at gmail.com (mailto:markthedeveloper at gmail.com)> wrote:
> > Preferring mocks over factories can help. Spork can help too by preloading
> > the Rails environment.
> > That's tended to be enough for me, although you can do distributed tests
> > too.
> > 
> > https://www.ruby-toolbox.com/categories/distributed_testing
> > 
> > Also I presume you're not hitting the web, but if you are then VCR with
> > WebMock is good
> > 
> > 
> > On 24 January 2012 19:02, Jonathan <j.fantham at gmail.com (mailto:j.fantham at gmail.com)> wrote:
> > > 
> > > Mine are really slow, but yesterday Glenn made a suggestion of using a
> > > ramdisk to speed the database access which seemed like a good idea! I
> > > haven't had the opportunity to try it yet but I read into it and if
> > > you're on *nix it seems pretty easy to do.
> > > 
> > > On 24 January 2012 09:57, Joel Chippindale
> > > <joel.chippindale at econsultancy.com (mailto:joel.chippindale at econsultancy.com)> wrote:
> > > > Test speed seems to be a perennial issue for our team.
> > > > 
> > > > Currently running a single spec file in our rails (v3.0, running under
> > > > REE)
> > > > app takes about 20 seconds and running a single cucumber scenario 30+
> > > > seconds. This is too slow for comfortable test driven
> > > > development/design.
> > > > 
> > > > We've recently started using the spec_no_rails pattern (as outlined by
> > > > Corey
> > > > Haines
> > > > here http://www.confreaks.com/videos/641-gogaruco2011-fast-rails-tests)
> > > > to
> > > > avoid loading rails, in some of our specs. This has enabled us to run
> > > > some
> > > > of our specs in couple of seconds (i.e. fast enough). However this
> > > > currently
> > > > only applies to the small subset of our specs that we have isolated from
> > > > rails. We'd like it if all our tests ran this fast.
> > > > 
> > > > How fast are your tests/specs/cucumber? Are they fast enough for you? If
> > > > they are, what have you done to make this so?
> > > > 
> > > > J.
> > > > 
> > > > --
> > > > Joel Chippindale
> > > > CTO - http://econsultancy.com
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Chat mailing list
> > > > Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> > > > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> > > 
> > > 
> > > _______________________________________________
> > > Chat mailing list
> > > Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> > > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org