Hacker News Reader

Comment by pbh | Hacker News Reader

I'm a (somewhat new) Rails developer now, and I'm really confused by the premise of this article.

Why are Rails test suites so slow? For a small app, one of my test suites takes about a minute for 100 tests. That's crazy!

This author seems to suggest persistence is the issue, but that doesn't make any sense to me. A disk hit is like, what, 10ms? Even if every one of my tests hit the DB once, and if there was no caching, that still would only be 1s. If I set the development database to be an in-memory SQLite, would that magically speed up my tests 100%? (I kind of doubt it.)

When I run rake tests, there seems to be some super long delay on the rake part, and not on the test part. Is the slow test speed related to loading and unloading the code in development (which apparently 1.9.2 is slow at)? Is this due to some rake bug? How would I even find out?

View on HN

The initial high load time is due to the combination of 1.9.2 and the new structure inside Rails 3. You can improve this by applying one of the approaches listed here: http://www.rubyinside.com/get-edge-ruby-faster-loading-ruby-...

or checking out the 1.9.3 release (I think it has one of these approaches applied).

That's clearly part of the answer: running 1.9.2-p180-patched instead of 1.9.2-p180 drops the total test suite time from 65s down to 52s.

But the test suite still takes 52s, of which only 12s is actually attributable to tests (since rails actually outputs the times for the test portion). FWIW, all of that measured test time seems to be for bcrypt (even with the test-specific initializer to make it faster) rather than persistence anyway.

Thanks for reducing things by 13s, at least. ;-)

EDIT: Actually, it looks like I'm down to 30--40s now, so that helped a lot. Basically, all of the non-test-time seems to be rails environment time (e.g., time bundle exec rake environment) which takes about 6-7s per run (times 3).

Yea, that's pretty much it. I would recommend looking at Spork - it pre-loads the Rails environments (the parts you want it to, at least) onto standing processes that you use to run tests. I consider Rails testing to be pretty much unusable without it.

Ah, down to 14s for 100 tests. I had originally avoided spork because it looked rspec only, but I guess there's spork-testunit as well.

Thanks!

Spork is awesome, but has its "gotchas" when it doesn't reload properly. I recommend reading this: https://github.com/timcharper/spork/wiki/Spork.trap_method-J... and applying whatever there is relevant to your project and also using Guard-Spork.

Reply on news.ycombinator.com