[rspec-users] about spec.opts and command line options and global options

David Chelimsky dchelimsky at gmail.com
Wed Jul 28 15:27:58 EDT 2010

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.


More information about the rspec-users mailing list