--options file quirky with --drb


#1

putting --drb in my spec.opts file has some unexpected results.

$ spec --drb --colour --format specdoc --loadby mtime --reverse -G
spec/spec.opts
$ spec spec/models/a_model_spec.rb -O spec/spec.opts
$

it just returns right away, with no output.

but…
$ spec --colour --format specdoc --loadby mtime --reverse -G spec/
spec.opts
$ spec spec/models/campaign_spec.rb -O spec/spec.opts
:
:
lots of pretty spec output
:
:
$

interestingly, if i include a spec file in the call that generates the
options file, like
$ spec spec/models/campaign_spec.rb --drb --colour --format specdoc –
loadby mtime --reverse -G spec/spec.opts
then running those options like this works as expected, even with –
drb.
$ spec spec/models/a_model_spec.rb -O spec/spec.opts

of course, that isn’t a very useful way to use rspec, and its
incompatible with my rspec holy grail dreams:
http://wiki.github.com/dchelimsky/rspec/spec_server-autospec-nearly-pure-bdd-joy

it seems that this would be a problem with options file loading, no?
anyone else able to reproduce this issue?


#2

On Thu, Mar 5, 2009 at 12:32 PM, Higgaion removed_email_address@domain.invalid
wrote:

putting --drb in my spec.opts file has some unexpected results.

$ spec --drb --colour --format specdoc --loadby mtime --reverse -G
spec/spec.opts
$ spec spec/models/a_model_spec.rb -O spec/spec.opts
$

it just returns right away, with no output.

What version of rspec are you running? This should be fixed in git.

interestingly, if i include a spec file in the call that generates the
options file, like
$ spec spec/models/campaign_spec.rb --drb --colour --format specdoc –
loadby mtime --reverse -G spec/spec.opts
then running those options like this works as expected, even with –
drb.
$ spec spec/models/a_model_spec.rb -O spec/spec.opts

Never heard that before :slight_smile: - obviously not intended.


#3

On Mar 5, 1:09 pm, David C. removed_email_address@domain.invalid wrote:

What version of rspec are you running? This should be fixed in git.

rspec 1.1.12.

i installed the plugins from git, as per the instructions here:
http://wiki.github.com/dchelimsky/rspec/rails
and it worked beautifully, as in spec_server and autospec talking
together*

one issue: now all of my route generation specs that illustrate
differentiation on http method are failing. ex:

Test::Unit::AssertionFailedError in ‘UsersController route generation
should route users’s ‘update’ action correctly’
The recognized options <{“action”=>“show”, “id”=>“1”,
“controller”=>“users”}> did not match <{“action”=>“update”, “id”=>“1”,
“controller”=>“users”}>, difference: <{“action”=>“update”}>

here it thought put was get.

i guess that’s why its the edge version :slight_smile:

  • with one minor change:

vendor/plugins/rspec/lib/spec/runner/drb_command_line.rb

  •      DRb.start_service("druby://localhost:0")
    
  •      DRb.start_service("druby://127.0.0.1:0")
    

i always have to change that because i build ruby from macports.


#4

On Thu, Mar 5, 2009 at 3:18 PM, Higgaion removed_email_address@domain.invalid
wrote:

What version of rspec are you running? This should be fixed in git.

rspec 1.1.12.

i installed the plugins from git, as per the instructions here:
http://wiki.github.com/dchelimsky/rspec/rails
and it worked beautifully, as in spec_server and autospec talking
together*

Great.

here it thought put was get.

i guess that’s why its the edge version :slight_smile:

This is doc’d here:
http://github.com/dchelimsky/rspec-rails/blob/master/Upgrade.markdown

  • with one minor change:

vendor/plugins/rspec/lib/spec/runner/drb_command_line.rb

  •      DRb.start_service("druby://localhost:0")
    
  •      DRb.start_service("druby://127.0.0.1:0")
    

i always have to change that because i build ruby from macports.

Maybe we need to make that configurable.

Thanks,
David


#5

On Mar 5, 3:18 pm, Higgaion removed_email_address@domain.invalid wrote:

it just returns right away, with no output.
differentiation on http method are failing. ex:

ok, i read some code and i see that rspec is now using
assert_recognizes, which expects a :method option. so if i change

route_for(:controller => ‘users’, :action => ‘update’, :id =>
‘1’).should == “/users/1”

to

route_for(:controller => ‘users’, :action => ‘update’, :id =>
‘1’).should == { :path => “/users/1”, :method => :put }

the assertion passes (and is a little more descriptive).