Getting 'no such file to load' for specjour/configuration
coreyhaines opened this issue · 11 comments
Did a gem install, get this whenever running:
/Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/specjour-0.4.0/lib/specjour/worker.rb:37:in run_tests': no such file to load -- specjour/configuration (LoadError) from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/specjour-0.4.0/lib/specjour/worker.rb:53:insend'
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/specjour-0.4.0/lib/specjour/worker.rb:53:in start' from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/specjour-0.4.0/lib/specjour/cli.rb:84:inwork'
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/thor-0.14.6/lib/thor/task.rb:22:in send' from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/thor-0.14.6/lib/thor/task.rb:22:inrun'
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/thor-0.14.6/lib/thor/invocation.rb:118:in invoke_task' from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/thor-0.14.6/lib/thor.rb:263:indispatch'
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/thor-0.14.6/lib/thor/base.rb:389:in start' from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/specjour-0.4.0/lib/specjour/cli.rb:18:instart'
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/gems/specjour-0.4.0/bin/specjour:5
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/bin/specjour:19:in `load'
from /Users/coreyhaines/.rvm/gems/ruby-1.8.7-p334@mercuryapp/bin/specjour:19
Do you have an older version of specjour installed on either the host machine or any listening worker machines?
Nope. Running it all local on a fresh machine. 0.4.0 is the version.
what was the resolution? I have the same issue after installing 0.4.0
As far as I know...the issue is unresolved. @kaeverett, what ruby version are you using?
Thanks for responding! I figured it out and have been meaning to post. This is a class loading issue. The only way I've been able to get remote listeners working is to run 'specjour listen' from a RAILS_ROOT (any project) that has specjor in the Gemfile
WIth a few desktops in the office, we've dropped our 30minutes to ~5minutes on a macbook pro. >3k specs
~Ken
Awesome, good news. I'll take a look and see about it.
My sweet spec suite takes about 10 seconds (~1000 specs), so I'm
curious to see if I can drop it even further. :)
On Fri, Apr 15, 2011 at 9:16 PM, kaeverett
reply@reply.github.com
wrote:
Thanks for responding! I figured it out and have been meaning to post. This is a class loading issue. The only way I've been able to get remote listeners working is to run 'specjour listen' from a RAILS_ROOT (any project) that has specjor in the Gemfile
WIth a few desktops in the office, we've dropped our 30minutes to ~5minutes on a macbook pro. >3k specs
~KenReply to this email directly or view it on GitHub:
#22 (comment)
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
@coreyhaines probably not. Specjour has some significant overhead when trying to find managers/starting up separate rails processes. It's best used when you're suite takes minutes to complete and you need a cheap solution to speed it up.
ah, sad to hear. It runs cucumber scenarios, yeah? That would be nice,
as my scenarios take upwards of 4 minutes to run.
-Corey
On Sat, Apr 16, 2011 at 9:48 AM, sandro
reply@reply.github.com
wrote:
@coreyhaines probably not. Specjour has some significant overhead when trying to find managers/starting up separate rails processes. It's best used when you're suite takes minutes to complete and you need a cheap solution to speed it up.
Reply to this email directly or view it on GitHub:
#22 (comment)
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
Yes, though it splits the suite up by file, not by scenario. If one file takes four minutes, you won't see any improvement. Give it a shot. Try running specjour features/. You may need to run it twice if the suite can't handle creating the db and running the tests in the same process (I blame rails 3 scope changes and db eager plugins).
Awesome, thanks. I'll try it. We don't have a 4-minute file. :)
On Sat, Apr 16, 2011 at 5:51 PM, sandro
reply@reply.github.com
wrote:
Yes, though it splits the suite up by file, not by scenario. If one file takes four minutes, you won't see any improvement. Give it a shot. Try running
specjour features/. You may need to run it twice if the suite can't handle creating the db and running the tests in the same process (I blame rails 3 scope changes and db eager plugins).Reply to this email directly or view it on GitHub:
#22 (comment)
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
Here are the results on my Macbook Air:
without specjour
227 scenarios (1 failed, 4 pending, 222 passed)
1783 steps (1 failed, 1 skipped, 4 pending, 1777 passed)
3m14.550s
real 3m22.767s
user 2m11.719s
sys 0m9.110s
with specjour
227 scenarios (4 pending, 223 passed)
1783 steps (4 pending, 1779 passed)
2m20.609s
real 2m44.640s
user 3m36.905s
sys 0m15.635s
On Sat, Apr 16, 2011 at 5:54 PM, Corey Haines coreyhaines@gmail.com wrote:
Awesome, thanks. I'll try it. We don't have a 4-minute file. :)
On Sat, Apr 16, 2011 at 5:51 PM, sandro
reply@reply.github.com
wrote:Yes, though it splits the suite up by file, not by scenario. If one file takes four minutes, you won't see any improvement. Give it a shot. Try running
specjour features/. You may need to run it twice if the suite can't handle creating the db and running the tests in the same process (I blame rails 3 scope changes and db eager plugins).Reply to this email directly or view it on GitHub:
#22 (comment)http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines