rspec users - Jul 2010 - about spec.opts and command line options and global options

Hello!

I have some questions/proposals which have been quite time on my mind
already.

Let''s suppose i have files under spec directory with the following
structure and contents:
# spec/helper.rb
module Helper
end

# spec/my_spec.rb
describe Helper do # notice the usage of constant Helper
end

#spec/spec.opts
--require spec/helper

If i execute "spec spec\my_spec.rb" then everything works as expected.
This solution gives me the possibility not to write all those require
statements into each spec file and i''m happy to use it so i can write
less duplicate code.

But there is a big problem if i want to enter some additional
parameters for some specific run. Let''s say i''d like to
execute this
command:
spec spec\my_spec.rb -b

I would expect this "-b" to merged with all the options from
spec.opts, but what actually happens is that all options from
spec.opts are ignored, thus the test above will fail because Helper
constant is missing. That just doesn''t make sense!

I also found the place in code where this magic happens:
# spec/runner/option_parser.rb

def parse_file_options(...)
...
        if options_file.nil? &&
           File.exist?(''spec/spec.opts'') &&
           !@argv.any?{|a| a =~ /^\-/ }
             options_file = ''spec/spec.opts''
        end
...
end

So, if there are any command line arguments specified then spec.opts
is ignored...

Let me bring some more realistic example if you might think that this
magic require in spec.opts is bad idea...

Let''s have a "normal" spec.opts file:
# spec.opts
--format
nested
-c

This means that i''m using nested formatter with colored output. Not a
bad idea, i guess.

But now if i want to execute only one example with -e, then my output
will not be nested nor colored because of this ignore statement
above... again, that doesn''t make sense, does it?

Also, is there any possibility to have global options - let''s say that
i want every project on my PC to have nested and colored output - what
shall i do? Any easy way to accomplish it programmatically if there''s
no built-in functionality yet?

Why is spec.opts hardcoded to be in spec directory? I would like it to
work like rake is searching for rakefiles - searches up in the
directory tree until finding rakefile.

I would like if spec.opts allowed to enter Ruby code so i wouldn''t
have to hardcode --require statement paths from working dir, but could
use something like File.dirname(__FILE__) + "/helper"...

In summary, my proposals for spec.opts would be:
1) Search for spec.opts upwards starting from spec directory.
2) Merge command line options with spec.opts - e.g have higher
priority for command line options, BUT preserve spec.opts if they''re
not overridden.
3) Make spec.opts to handle Ruby code.
4) Allow some way to specify global configuration options for RSpec.

I''m using RSpec 1.3.0 and don''t know how these situations are
handled
in RSpec 2 branches.

Hopefully my ideas make sense.

Jarmo Pertman
-----
IT does really matter - http://www.itreallymatters.net

On Jul 28, 2010, at 1:52 PM, Jarmo Pertman wrote:
> Hello!
> 
> I have some questions/proposals which have been quite time on my mind
> already.
> 
> Let''s suppose i have files under spec directory with the following
> structure and contents:
> # spec/helper.rb
> module Helper
> end
> 
> # spec/my_spec.rb
> describe Helper do # notice the usage of constant Helper
> end
> 
> #spec/spec.opts
> --require spec/helper
> 
> If i execute "spec spec\my_spec.rb" then everything works as
expected.
> This solution gives me the possibility not to write all those require
> statements into each spec file and i''m happy to use it so i can
write
> less duplicate code.
> 
> But there is a big problem if i want to enter some additional
> parameters for some specific run. Let''s say i''d like to
execute this
> command:
> spec spec\my_spec.rb -b
> 
> I would expect this "-b" to merged with all the options from
> spec.opts, but what actually happens is that all options from
> spec.opts are ignored, thus the test above will fail because Helper
> constant is missing. That just doesn''t make sense!
> 
> I also found the place in code where this magic happens:
> # spec/runner/option_parser.rb
> 
> def parse_file_options(...)
> ...
>        if options_file.nil? &&
>           File.exist?(''spec/spec.opts'') &&
>           !@argv.any?{|a| a =~ /^\-/ }
>             options_file = ''spec/spec.opts''
>        end
> ...
> end
> 
> So, if there are any command line arguments specified then spec.opts
> is ignored...
> 
> Let me bring some more realistic example if you might think that this
> magic require in spec.opts is bad idea...
> 
> Let''s have a "normal" spec.opts file:
> # spec.opts
> --format
> nested
> -c
> 
> This means that i''m using nested formatter with colored output.
Not a
> bad idea, i guess.
> 
> But now if i want to execute only one example with -e, then my output
> will not be nested nor colored because of this ignore statement
> above... again, that doesn''t make sense, does it?
> 
> Also, is there any possibility to have global options - let''s say
that
> i want every project on my PC to have nested and colored output - what
> shall i do? Any easy way to accomplish it programmatically if
there''s
> no built-in functionality yet?
> 
> Why is spec.opts hardcoded to be in spec directory? I would like it to
> work like rake is searching for rakefiles - searches up in the
> directory tree until finding rakefile.
> 
> I would like if spec.opts allowed to enter Ruby code so i wouldn''t
> have to hardcode --require statement paths from working dir, but could
> use something like File.dirname(__FILE__) + "/helper"...
> 
> In summary, my proposals for spec.opts would be:
> 1) Search for spec.opts upwards starting from spec directory.
> 2) Merge command line options with spec.opts - e.g have higher
> priority for command line options, BUT preserve spec.opts if
they''re
> not overridden.
> 3) Make spec.opts to handle Ruby code.
> 4) Allow some way to specify global configuration options for RSpec.
> 
> I''m using RSpec 1.3.0 and don''t know how these situations
are handled
> in RSpec 2 branches.
> 
> Hopefully my ideas make sense.
I think http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown might
answer some of your questions.

HTH,
David

Thank You!

If i understand correctly, then all the problems except #3 have been
solved in RSpec 2?

Nice that there are people with similar thoughts :)

Jarmo Pertman
-----
IT does really matter - http://www.itreallymatters.net

On Jul 28, 10:27?pm, David Chelimsky <dchelim... at gmail.com>
wrote:
> I thinkhttp://github.com/rspec/rspec-core/blob/master/Upgrade.markdownmight
answer some of your questions.
>
> HTH,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users