4 ms·

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 m

by pbh 15y ago

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?

keeran 15y ago
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-1-9-2-now-4973.html 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).
- pbh 15y ago
  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).
  - swampthing 15y ago
    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.
    - pbh 15y ago
      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!
      - arikfr 15y ago
        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-Jujutsu https://github.com/timcharper/spork/wiki/Spork.trap_method-J... and applying whatever there is relevant to your project and also using Guard-Spork.

by pbh 15y ago

keeran 15y ago

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-1-9-2-now-4973.html 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).

pbh 15y ago
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).
- swampthing 15y ago
  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.
  - pbh 15y ago
    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!
    - arikfr 15y ago
      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-Jujutsu https://github.com/timcharper/spork/wiki/Spork.trap_method-J... and applying whatever there is relevant to your project and also using Guard-Spork.