[rspec-users] Speeding up RSpec Tests

Ash Moran ash.moran at patchspace.co.uk
Thu Feb 14 15:29:54 UTC 2013

On 13 Feb 2013, at 22:51, Adam Sroka <adam.sroka at gmail.com> wrote:

> Why would you need to generate models with passwords for every spec? Why would you need to generate a password for *any* spec that wasn't specifically about authentication? 
> It seems like hacking BCrypt is a way to avoid the design problem rather than just taking it on. 

Agreed. I hit this problem a few years ago, and the suddenly increased spec run time revealed an unwanted coupling in the code. We refactored it to extract the BCrypt code entirely.

A better strategy I use now is to be aware what runtime dependencies new code pulls in, isolate the slow behaviour behind a small integration test, then remove it from the default spec run. On one project I had a few specs that needed Berkeley DB access, which was painfully slow, and I hacked Guard to only run those files if they were saved directly. This works quite well. (Admittedly, Rails makes it a lot harder to be aware what dependencies you're pulling in.)

And I pretty much disagree with that entire blog post.

>> Before going further, I assume you are already using Spork in your Rails project.
>> If not, you must start using it now, before reading the rest of the post.

The fact a spec run with one example takes 20 seconds because it depends on Rails to boot is saying something important. Spork might make a spec run 2 or 3 times as fast, but isolating your own code so it doesn't need Rails will make a spec run several orders of magnitude faster. Also, in my own attempt to use Spork, I found the monkeypatching it needs to do can cause subtle, hard-to-track-down weirdness. That was a while ago though, maybe it's fine now. Either way, it doesn't solve the design problems the slow specs are screaming to have fixed. 164 examples in 12.17 seconds is painfully slow.

This is my own experience, anyway.



More information about the rspec-users mailing list