[LRUG] Making your tests run fast enough?

[Ian Leitch]

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> 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> 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> 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
>> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> >
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>