[rspec-users] Rails code reloading in RSpec test environment?
Ash Moran
I've worked on a couple of Rails 3 apps recently and the test feedback loop is killing me. With no modifications, it takes 15-25 seconds to run a single example. I've avoided Spork so far, but I've tried Spin[1]. Spin shaves a few seconds off but it's still agonising. I've also experimented with multiple Guard groups and other hacks to run isolated code in lib/, but a lot of the code can't be isolated (all the controllers, for example).
My last resort is to try and run Rails against an environment with `config.cache_classes = false`. Has anyone tried this (and got it working)? I imagine it would have to run tests over DRb, which I've only used with Spork before. The last mention of "cache_classes" on this list was in 2009, so I thought I'd check before I invested time in it in case there any major obstacles.
Any help appreciated
Cheers
Ash
[1] http://jstorimer.github.com/spin/
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashmoran
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Andrew Premdas
> Hi
>
> I've worked on a couple of Rails 3 apps recently and the test feedback loop is killing me. With no modifications, it takes 15-25 seconds to run a single example. I've avoided Spork so far, but I've tried Spin[1]. Spin shaves a few seconds off but it's still agonising. I've also experimented with multiple Guard groups and other hacks to run isolated code in lib/, but a lot of the code can't be isolated (all the controllers, for example).
>
> My last resort is to try and run Rails against an environment with `config.cache_classes = false`. Has anyone tried this (and got it working)? I imagine it would have to run tests over DRb, which I've only used with Spork before. The last mention of "cache_classes" on this list was in 2009, so I thought I'd check before I invested time in it in case there any major obstacles.
>
> Any help appreciated
>
> Cheers
> Ash
>
Destroy All Software that might help also - the one about extracting
domain objects (or something like that).
HTH
Andrew
ps
>
> [1] http://jstorimer.github.com/spin/
>
> --
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashmoran
>
> _______________________________________________
> rspec-users mailing list
> rspec...@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
------------------------
Andrew Premdas
blog.andrew.premdas.org
Justin Ko
On Nov 22, 2011, at 4:52 PM, Andrew Premdas wrote:
> On 22 November 2011 20:31, Ash Moran <ash....@patchspace.co.uk> wrote:
>> Hi
>>
>> I've worked on a couple of Rails 3 apps recently and the test feedback loop is killing me. With no modifications, it takes 15-25 seconds to run a single example. I've avoided Spork so far, but I've tried Spin[1]. Spin shaves a few seconds off but it's still agonising. I've also experimented with multiple Guard groups and other hacks to run isolated code in lib/, but a lot of the code can't be isolated (all the controllers, for example).
>>
>> My last resort is to try and run Rails against an environment with `config.cache_classes = false`. Has anyone tried this (and got it working)? I imagine it would have to run tests over DRb, which I've only used with Spork before. The last mention of "cache_classes" on this list was in 2009, so I thought I'd check before I invested time in it in case there any major obstacles.
>>
>> Any help appreciated
>>
>> Cheers
>> Ash
>>
> Use Ruby 1.8.7 its much faster. There is a very good screencast on
> Destroy All Software that might help also - the one about extracting
> domain objects (or something like that).
Anytime someone suggests using 1.8, a Chinchilla explodes. 1.9.3 has the "slow require" fix - please use that if it is your concern.
Andrew Premdas
>
> On Nov 22, 2011, at 4:52 PM, Andrew Premdas wrote:
>
>> On 22 November 2011 20:31, Ash Moran <ash....@patchspace.co.uk> wrote:
>>> Hi
>>>
>>> I've worked on a couple of Rails 3 apps recently and the test feedback loop is killing me. With no modifications, it takes 15-25 seconds to run a single example. I've avoided Spork so far, but I've tried Spin[1]. Spin shaves a few seconds off but it's still agonising. I've also experimented with multiple Guard groups and other hacks to run isolated code in lib/, but a lot of the code can't be isolated (all the controllers, for example).
>>>
>>> My last resort is to try and run Rails against an environment with `config.cache_classes = false`. Has anyone tried this (and got it working)? I imagine it would have to run tests over DRb, which I've only used with Spork before. The last mention of "cache_classes" on this list was in 2009, so I thought I'd check before I invested time in it in case there any major obstacles.
>>>
>>> Any help appreciated
>>>
>>> Cheers
>>> Ash
>>>
>> Use Ruby 1.8.7 its much faster. There is a very good screencast on
>> Destroy All Software that might help also - the one about extracting
>> domain objects (or something like that).
>
> Anytime someone suggests using 1.8, a Chinchilla explodes. 1.9.3 has the "slow require" fix - please use that if it is your concern.
>
Yeh I know, but have you actually tried it out and got benchmarks to
prove that 1.9.3 is fast enough? I've been trying for the last few
weeks to get the rails test cycle going as quickly as possible. I'd
like to be using 1.9.x but its just been to slow. I've tried
fast_require patches, done lots of googling, used rvm to try different
versions etc. etc.. Currently the Rails test cycle is much faster in
1.8.7 - and for me the speed of the test cycle is the most important
thing. Using rvm I can always run the app on 1.9.x in CI and
production (so long as I create it using 1.8.x). Even using 1.8.7 the
time to run a model spec is a couple of seconds, which really is still
to slow, but its bearable. As soon as this becomes 4 or 5 seconds then
my style of programming has to change, and I don't want that.
If you have some uber fast version of 1.9.3 working reliably with
Rails 3.1.x and RVM running a single spec on an empty rails project in
less than 2 seconds - please point me in that direction with a link to
the particular patch/article/whatever.
All best
Andrew
Ash Moran
On 23 Nov 2011, at 07:19, Andrew Premdas wrote:
>>> Use Ruby 1.8.7 its much faster. There is a very good screencast on
>>> Destroy All Software that might help also - the one about extracting
>>> domain objects (or something like that).
>>
>> Anytime someone suggests using 1.8, a Chinchilla explodes. 1.9.3 has the "slow require" fix - please use that if it is your concern.
>
> Yeh I know, but have you actually tried it out and got benchmarks to
> prove that 1.9.3 is fast enough? I've been trying for the last few
> weeks to get the rails test cycle going as quickly as possible. I'd
> like to be using 1.9.x but its just been to slow.
My feeling is that using 1.8.7 over 1.9.3 to gain test speed is throwing the baby out with the bathwater. Ruby 1.9 has been around a long time and has useful advantages over 1.8.7. The two key points to me are:
- the slow loading time highlights a design problem, not a performance problem: it should not be necessary to load so much code to test a small part of an app (we are limited as to how much we can extract from the Rails framework)
- holding back to 1.8.7 will turn the minor tremors from a gradual shift to 1.9.3 into a tectonic quake (I'm guessing chinchillas don't like earthquakes)
For these reasons I'm not prepared to compromise the dev environment and rewrite our 1.9 code to work in 1.8.7, so I'll experiment later with turning on code reloading. If that doesn't work I'm not sure what I'll do…
Ash
Andrew Premdas
>
> On 23 Nov 2011, at 07:19, Andrew Premdas wrote:
>
>>>> Use Ruby 1.8.7 its much faster. There is a very good screencast on
>>>> Destroy All Software that might help also - the one about extracting
>>>> domain objects (or something like that).
>>>
>>> Anytime someone suggests using 1.8, a Chinchilla explodes. 1.9.3 has the "slow require" fix - please use that if it is your concern.
>>
>> Yeh I know, but have you actually tried it out and got benchmarks to
>> prove that 1.9.3 is fast enough? I've been trying for the last few
>> weeks to get the rails test cycle going as quickly as possible. I'd
>> like to be using 1.9.x but its just been to slow.
>
> My feeling is that using 1.8.7 over 1.9.3 to gain test speed is throwing the baby out with the bathwater. Ruby 1.9 has been around a long time and has useful advantages over 1.8.7. The two key points to me are:
>
> - the slow loading time highlights a design problem, not a performance problem: it should not be necessary to load so much code to test a small part of an app (we are limited as to how much we can extract from the Rails framework)
>
> - holding back to 1.8.7 will turn the minor tremors from a gradual shift to 1.9.3 into a tectonic quake (I'm guessing chinchillas don't like earthquakes)
>
> For these reasons I'm not prepared to compromise the dev environment and rewrite our 1.9 code to work in 1.8.7, so I'll experiment later with turning on code reloading. If that doesn't work I'm not sure what I'll do…
>
> Ash
>
Fair enough, good luck, and do let us know if you make progress with
it. I'd love it if we could find away to make 1.9.x faster for this
task
All best
Andrew
> --
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashmoran
>
> _______________________________________________
> rspec-users mailing list
> rspec...@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
------------------------
Andrew Premdas
blog.andrew.premdas.org
Jason Nah
The issue I've found is rails loading everything. So the only 'simple
fix' is the spork kind (ie process fork)
Cheers,
Jason