[LRUG] Speeding up Specs and Cukes

Joel Chippindale joel.chippindale at gmail.com
Wed Feb 16 14:41:44 PST 2011


I tried out and then ditched spork at the end of 2009. The reasons for
trying to get it running were the same as yours and the reasons for ditching
it were the things that it looks like guard is meant to resolve (i.e. I
found it to easy to end up running tests against stale codei), so I'd be
very interested if you make any progress with this.

In the meantime have two other suggestions that may improve your
rspec/cucumber test performance

1. Skip dropping and rebuilding the database between cucumber runs.

Typically in development I run a small set of cucumber tests (by tagging
them @wip). The rake task 'cucumber:wip' can be used to run these but this
task depends on ''db:test:prepare' to drop and rebuild the database as part
of the run.

I have found that our our project roughly half the time spent running
'cucumber:wip'  is taken up with this database reset. Since the database
rarely needs to change (in terms of schema) and our cucumber set up already
ensures that no data leaks between scenarios, I run a modified version of
the 'cucumber:wip' task, like the one below, which does not reset the
database to speed up the tests (giving a performance improvement of roughly
50% on smaller numbers of scenarios.

    Cucumber::Rake::Task.new(:wip_fast, 'Run features that are being worked
on WITHOUT running db:test:prepare') do |t|
      t.binary = vendored_cucumber_bin
      t.fork = true # You may get faster startup if you set this to false
      t.profile = 'wip'
    end

2. Tune your ruby garbage collection.

Ruby process may be spending a lot of time in garbage collection when you
are running your tests. Typically you are CPU bound rather than memory bound
when running tests and so ideally you would like ruby garbage collection
less often than perhaps it does out of the box.

I use REE which makes it very easy to tune garbage collection (see
http://www.rubyenterpriseedition.com/documentation.html#_garbage_collector_performance_tuning)
and find that the following settings improve the performance of running the
cucumber scenarios on our project by 25% or more.

  RUBY_HEAP_MIN_SLOTS=1250000
  RUBY_HEAP_SLOTS_INCREMENT=500000
  RUBY_HEAP_SLOTS_GROWTH_FACTOR=1
  RUBY_GC_MALLOC_LIMIT=30000000
  RUBY_HEAP_FREE_MIN=100000

J.

On 11 February 2011 10:15, Hakan Ensari <hakan.ensari at papercavalier.com>wrote:

> I have a question to you all LRUGers.
>
> Being fed up with the excruciatingly slow boot of Rails when running tests,
> I finally got around to setting up Spork and Guard in a project. After
> some fiddling, everything seemed wired up. Or so I thought.
>
> For a starter, I cannot do ruby-debug if I start with `bundle exec guard.` It
> does work if I start spork without guard, but what's the point of spork
> without guard?
>
> Second bummer: Spork doesn't handle nested Cucumber feature folders out of
> the box. The answer to this I suppose is easier and involves some magic
> incantation in the `cucumber.yml` file requiring the feature folder etc.,
> but I was so fed up with #1 that I did not get around figuring out the fix
> for this either.
>
> Anyone with a functional relationship with the above tools care to share
> their story?
>
> The gems involved -
>
>   * rspec (2.5.0)
>   * cucumber (0.10.0)
>   * cucumber-rails (0.4.0.beta.1 f3002fa)
>   * guard (0.3.0)
>   * guard-cucumber (0.2.3)
>   * guard-rspec (0.1.9)
>   * guard-spork (0.1.4)
>   * spork (0.9.0.rc3)
>
> --
> Hakan Ensari
> http://hakanensari.com
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110216/de54fde7/attachment.html>


More information about the Chat mailing list