CODEWITHSUNDEEP
ruby-on-railstesting
Milan Novota
Milan Novota

Reputation: 15596

Speed of running a test suite in Rails

I have 357 tests (534 assertions) for my app (using Shoulda). The whole test suite runs in around 80 seconds. Is this time OK? I'm just curious, since this is one of my first apps where I write tests extensively. No fancy stuff in my app.

Btw.: I tried to use in memory sqlite3 database, but the results were surprisingly worse (around 83 seconds). Any clues here?

I'm using Macbook with 2GB of RAM and 2GHz Intel Core Duo processor as my development machine.

Upvotes: 4

Views: 1978

Answers (7)

Danny Hawkins
Danny Hawkins

Reputation: 31

You should try this method https://github.com/dchelimsky/rspec/wiki/spork---autospec-==-pure-bdd-joy- using spork to spin up a couple of processes that stay running and batch out your tests. I found it to be pretty quick.

Upvotes: 2

Grimmo
Grimmo

Reputation: 111

As opposite to in-memory SQLite, you can put a MySQL database on RAMDISK (on Windows) or on tmpfs on Linux.

MySQL has a very efficient buffering, so putting database in memory does not help a lot until you update a lot of data really often.

More significant is the way of test isolation and data preparation for each test.

You can use transactional fixtures. That means that each test will be wrapped into transaction and thus next test will start at the initial point.

This is faster than cleaning up the database before each test.

There are situations when you want to use both transactions and explicit data erasing, here is a good article about it: http://www.3hv.co.uk/blog/2009/05/08/switching-off-transactions-for-a-single-spec-when-using-rspec/

Upvotes: 0

zed_0xff
zed_0xff

Reputation: 33217

You can experiment with preloading fixtures, but it will be harder to maintain, and, IMHO, not worth it's speed improvements (20% maximum I think, but it depends)

It's known that SQLite is slower than mysql/pgsql, excepting very small, tiny DBs.

As someone already said, you can put mysql (or other DB) datafiles on some kind of RAMDisk (I use tmpfs on linux).

PS: we have 1319 Rspec examples now, and it runs for 230 seconds on C2D-3Ghz-4GRam, and I think it's fine. So, yours is fine too.

Upvotes: 0

Codebeef
Codebeef

Reputation: 43996

If you're looking to speed up the runtime of your test suite, then I'd use a test server such as this one from Roman Le Négrate.

Upvotes: 1

Toby Hede
Toby Hede

Reputation: 37133

Large test suites can take some time to run.

I generally use "autospec -f" when developing, this only runs the specs that have changed since the last run - makes it much more efficient to keep your tests running.

Of course, if you are really serious, you will run a Continuous Integration setup like Cruise Control - this will automate your build process and run in the background, checking out your latest building and running the suite.

Upvotes: 1

DanSingerman
DanSingerman

Reputation: 36502

It really depends on what your tests are doing. Test code can be written efficiently or not in exactly the same way as any other code can.

One obvious optimisation in many cases is to write your test code in such a way that everything (or as much as possible) is done in memory, as opposed to many read/writes to the database. However, you may have to change your application code to have the right interfaces to achieve this.

Upvotes: 1

tsimon
tsimon

Reputation: 8010

I don't feel this question is rails specific, so I'll chime in.

The main thing about testing is that it should be fast enough for you to run them a lot (as in, all the time). Also, you may wish to split your tests into a few different sets, specifically things like 'long running tests' and 'unit tests'.

One last option to consider, if your database setup is time consuming, would be to create your domain by restoring from a backup, rather than doing a whole bunch of inserts.

Good luck!

Upvotes: 2

Related Questions