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.
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashmoran