views:

267

answers:

6

I have a Rails application with over 2,000 examples in my RSpec tests. Needless to say, it's a large application and there's a lot to be tested. Running these tests at this point is very inefficient and because it takes so long, we're almost at the point of being discouraged from writing them before pushing a new build. I added --profile to my spec.opts to find the longest running examples and there are at least 10 of them that take an average of 10 seconds to run. Is that normal amongst you RSpec experts? Is 10 seconds entirely too long for one example? I realize that with 2,000 examples, it will take a non-trivial amount of time to test everything thoroughly - but at this point 4 hours is a bit ludicrous.

What kind of times are you seeing for your longest running examples? What can I do to troubleshoot my existing specs in order to figure out bottlenecks and help speed things up. Every minute would really help at this point.

+1  A: 

You can use Spork. It has support for 2.3.x ,

http://github.com/timcharper/spork

or ./script/spec_server which may work for 2.x

Also you can edit the database configuration ( which essentially speeds up the database queries etc ), which will also increase performance for tests.

Rishav Rastogi
Spork is awesome. It also works on Rails 3, with a bit of hacking. But one thing to note with Spork on Rails 3 is that it doesn't seem to pick up changes in controllers, so you'll need to restart it every so often. But anyway, Spork is really awesome, the speed improvement of the tests is very significant.
AboutRuby
Spork is for speeding up startup only, not tests. So with a lot of specs, the advantage is insignificant.
Tass
A: 

faster_require gem might help you. Besides that your only way is to (like you did) profile and optimize, or use spork or something that runs your specs in parallel for you. http://ruby-toolbox.com/categories/distributed_testing.html

rogerdpack
+1  A: 

10 seconds per example seems like a very long time. I've never seen a spec that took more than one second, and most take far less. Are you testing network connections? Database writes? Filesystem writes?

Use mocks and stubs as much as possible - they are much faster than writing code that hits the database. Unfortunately mocking and stubbing also take more time to write (and are harder to do correctly). You have to balance the time spent writing tests vs. the time spent running tests.

I second Andrew Grimm's comment about looking into a CI system which might allow you to parallelize your test suite. For something that size, it might be the only viable solution.

zetetic
yeah if it's 10 seconds I would profile it and see where the bottleneck is
rogerdpack
A: 

You can try http://github.com/ngauthier/hydra

Tass
A: 

For a great cookbook on improving the performance of your test suite, check out the Grease Your Suite presentation.

He documents a 45x speedup in test suite run time by utilizing techniques such as:

marshally
I like the links, but not the presentation. Index cards for someone's speach are a prompt for the speaker to fill in the meat of the presentation.
Brian Maltzan
A: 

Checkout this presentation: http://grease-your-suite.heroku.com/#1