Upcoming and OnDemand Webinars View full list

Reasonable RSpec Config for Clean, and Slightly Faster, Specs

Steven Harman

Database-bound tests are a drag. Inconsistent tests are a pain. Database-bound,
inconsistently failing tests are the worst!

The following commit message is from a real code base:

Run in transactions by default.

When we added controller specs they weren’t being run w/any kind of DB
cleaner b/c there was no default strategy and they weren’t explicitly
included in a group. Now, we use :transactions be default, setting request
specs to use :truncation

Also, I saw a 2 second speed up from this change!

myself

Let’s look at what we changed in this commit to turn our inconsistently failing
database-bound tests into slightly faster, consistent, database-bound tests.

Prefer isolated tests

Whenever possible I strive to write isolated tests, stubbing out collaborators
where necessary, while driving from the outside of the system downward, one
layer at time. However, there are occasions where you must hit the database.

Testing ActiveRecord scopes and higher-order acceptance tests are two cases
where I believe it is okay to have tests which cross layers, and may even hit a
database.

Ensuring idempotent tests

I don't always write database-bound tests, but when I do, I prefer them
to be idempotent.

When you are going to hit a database, your
tests should be good citizens and clean up after themselves.

If you’re using RSpec with Rails your tests run within a transaction
by default. Yay!

Unfortunately, test tooling like Capybara won’t work with
transactions and you’ll be forced to resort to techniques like database
truncation to ensure proper data clean up. I really like Database
Cleaner
for that job.

An example RSpec configuration

What follows is the RSpec configuration we ended up with after the previously
mentioned commit. Or at least a very close approximation of it

A few key take aways:

To start, turn off RSpec’s built-in transaction support as we’ll handle that
with database_cleaner.

Next we configure a default clean-up strategy for every RSpec suite. We’ll use
transactions by default, being sure to clean up any thing that might have been
left behind with a truncation.

We make a special exception for request specs, which are often driven by
Capybara, and switch them over to truncation.

Then, before every test runs start Database Cleaner

And finally, after every test runs, tell Database cleaner to clean up using
whatever strategy it is currently configured with.

For posterity’s sake, you can see a full before and after of
this particular spec_helper on The GitHubs.

Not Happy with Your Current App, or Digital Product?

Submit your event

Let's Discuss Your Project

Let's Discuss Your Project