Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Rake Task doesn't pick up Configuration #682

PragTob opened this Issue · 11 comments

5 participants


Hi all,

at first thanks for RSpec it has been the testing framework of my choice for quite some time and it's awesome!

Now to the problem:
The rake task doesn't use the RSpec::Core::Configuration with defaults and further configured by RSpec.configure do .. end at all, as far as I can tell.

In general I believe it's not good to have things like the pattern for files to execute defined twice (in the task and in the Configuration) as this way there is no single source. I believe it would be good to incorporate the Configuration into the Rake task or am I missing something?

Furthermore that would also allow integrate other gems to integrate more smoothly with RSpec.
I stumbled upon this problem as the default rspec rake task doesn't pick up the .feature files of turnip while the default rspec command does so (since it uses the Configuration).

Turnip configures RSpec the following way:

::RSpec::Core::Configuration.send(:include, Turnip::RSpec::Loader)

::RSpec.configure do |config|
  config.include Turnip::RSpec::Execute, turnip: true
  config.include Turnip::Steps, turnip: true
  config.pattern << ",**/*.feature"

I could code a quick fix using the patterns defined in RSpec::Core::Configuration in the rake task and send a pull request. However I kind of feel like more information (at least defaults) should be taken from the Configuration. I didn't dive too deep into the code just yet though.

So what do you think would be the best approach? Or maybe an incremental migration getting more and more information from the Configuration?

I would be very happy to try to solve this and make a pull request :-)

Thanks + Cheers,

@PragTob PragTob referenced this issue in jnicklas/turnip

Feature files are not loaded with rake spec #79


Thanks for opening this issue.

The rake task configuration and RSpec.configure { } have different purposes:

  • RSpec.configure { } is intended for runtime configuration of things like metadata, filters, included or extended modules, etc.
  • The rake task configuration is intended to be used to configure what shell command gets run.

The pattern option is a bit tricky in that if you tried to only set it in RSpec.configure { }, we'd have a chicken-and-egg problem: RSpec.configure { } goes in some file that rspec loads, but the pattern option tells it how to find files to load. Without the pattern option being specified first, before rspec has loaded any of your files, it doesn't know what your files are that it should load--so it would never run your configure block to allow it to set the pattern option.

So, the pattern option is passed in as a command line option, and the rake task options simply configure what command line switches are passed to the rspec command.

I'm actually a little surprised that the pattern option is even available to set in the RSpec.configure block since I don't really think it makes sense to set it there due to the chicken-and-egg problem. My guess is that it's there because the rspec command uses the configuration object to store the flags/options passed in at the command line (since it's a natural place for it).

As for your problem with Turnip: I've never used turnip, so it's hard for me to say what's best, but ultimately RSpec just uses its pattern option to find files on the filesystem to load. That's all it does. Can turnip take care of loading the .feature files it is meant to manage?


I've long wished we could cleanly separate run options (formatters, files to load, etc) from structural options (includes, hooks, etc). If there were a clean separation we could store run options in a separate object that isn't accessible via RSpec.configure, but there are a few issues with this.

One problem with this is that the Configuration object is used to build command line options to be passed over DRb, so it needs to support all of the options that arguably only belong on the command line. That could be solved by separating run options out into a different object that is not accessible from RSpec.configure, but that's not the only issue: there are also options that make sense to have in both places, e.g. filters/tags. It's really nice to be able to write this in spec_helper.rb:

RSpec.configure do |c|
  c.filter_run_including :focus
  c.run_all_when_everything_filtered = true

... and still use additional tags on the command line or in task.spec_opts in a rake task declaration. If that's the only one, then I think it would be a reasonable tradeoff to remove those from RSpec.configure and support them only as command line arguments, which can be stored .rspec file so you still get the benefit of storage.

@spicycode any thoughts on this? IIRC you were in favor of being able to do everything from RSpec.configure.


Just want to point out that turnip wouldn't be able to add its files if pattern weren't available to be configured. Sure people could do that themselves, but it would make setting up the gem a lot more difficult.


Just want to point out that turnip wouldn't be able to add its files if pattern weren't available to be configured. Sure people could do that themselves, but it would make setting up the gem a lot more difficult.

It's available to be configured at the command line and from the rake task (which generates the command line command). Within RSpec.configure it's not supported because by the time that runs, RSpec has already used the pattern option to determine what files to load.

Is there a reason turnip can't simply load the additional files itself?


We want Turnip to be as thin a layer on top of RSpec as possible, so ideally that means using the same mechanisms that are available within RSpec itself. Of course, it wouldn't be hard to glob after the relevant files and load them from within Turnip, but it seems like using the official RSpec api was a better call. Are you saying that the fact that RSpec.configuration exposes pattern is accidental? It does after all work, so obviously the API is there, is it not meant to be used?


RSpec uses it internally to store and build drb options. Per comments earlier this thread, we should probably figure out a way to remove it from the Configuration object's API since, as @myronmarston points out, it can't really do anything useful in the current process.


I don't understand why it would work any differently for the CLI tool, where it works, and not the Rake task, where it doesn't, especially if the Rake task just shells out to the CLI anyway. That's what's confusing me. You guys are saying it doesn't work, but it does.


I'm saying RSpec.configure won't work. I'm not saying the rake task won't work.


I'm also a bit confused at the moment.. so as a short recap with the current turnip and the current rspec the behaviour is the following:

  1. Just running rspec on the CLI works and executes all .feature (and all *_spec.rb) files as expected
  2. Running rake spec does not pick up on the additional .feature files and only executes the normal rspec _spec.rb files. The .feature files can be added to the rake task though through defining an own rake task etc.

I don't really understand the other uses of pattern in rspec yet - will have to look at the code base again to get a clearer view.

Thanks for the discussion everyone! :-)


Ping! Is this still an issue? Or do we need a new issue for:

figure out a way to remove it from the Configuration object's API since


@cupakromer -- thanks for pinging us on this. I've opened #947 for the work item you mentioned. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.