Skip to content
This repository has been archived by the owner on Jan 15, 2024. It is now read-only.

rspec can't find spec_helper #31

Closed
nicgrayson opened this issue Jul 14, 2013 · 7 comments
Closed

rspec can't find spec_helper #31

nicgrayson opened this issue Jul 14, 2013 · 7 comments

Comments

@nicgrayson
Copy link

chefspec             | bundle exec rspec /Users/ngrayson/banno/cookbooks/ntp
chefspec             | /Users/ngrayson/banno/cookbooks/ntp/spec/defalt_spec.rb:1:in `require': cannot load such file -- spec_helper (LoadError)
chefspec             | from /Users/ngrayson/banno/cookbooks/ntp/spec/defalt_spec.rb:1:in `<top (required)>'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/configuration.rb:896:in `load'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/configuration.rb:896:in `block in load_spec_files'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/configuration.rb:896:in `each'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/configuration.rb:896:in `load_spec_files'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/command_line.rb:22:in `run'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/runner.rb:80:in `run'
chefspec             | from /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.14.3/lib/rspec/core/runner.rb:17:in `block in autorun'
chefspec             | Terminated with a non-zero exit status. Strainer assumes this is a failure.
chefspec             | FAILURE!

Here is the simple cookbook I'm creating to test this.
https://github.com/nicgrayson/chef-ntp

@trinitronx
Copy link

It looks like the path to ./spec isn't on the load path in the strainer sandbox environment. You can probably try using require_relative 'spec_helper' in your default_spec.rb. Or, you might want to add a .rspec file to add -I ./spec to the $LOAD_PATH.

I'm still slightly confused by this behavior, since supposedly RSpec 2 always has the spec folder in the load path. If anyone can clear this up for me, please do ;-)

@nicgrayson
Copy link
Author

require_relative works for now, thanks for the suggestion.

@sethvargo
Copy link
Contributor

@nicgrayson @trinitronx while that "works" (and so does changing the command to (cd $COOKBOOK && rspec), I don't like either of those solutions. If you have any ideas on how I might patch strainer to account for this edge case, I'm all ears 😄

@trinitronx
Copy link

After looking at what strainer is doing to run the chefspec tests, now it's starting to make sense. Since rspec is started with the current working directory set to the $SANDBOX path, it's no wonder that the my_cookbook/spec directory which contains the spec_helper.rb is not on the load path... There is no: ${SANDBOX}/./spec directory. RSpec needs the ${SANDBOX}/${COOKBOOK}/spec dir to be on the load path.

There are a couple solutions:

  1. Use require_relative 'spec_helper' in your tests (not so DRY with many tests)
  2. Run strainer rspec tests from the cookbook directory
  3. Configure RSpec to include the path to the cookbook's ./spec dir (There are many ways to do this)

@sethvargo
Copy link
Contributor

@trinitronx is this something I can fix on the strainer end? FWIW, the same thing happens with Test Kitchen.

@trinitronx
Copy link

Yes, you can probably fix this within strainer since rspec is spawned by strainer, and when it comes down to it, strainer is in control of it's sandbox directory, and the commands it spawns. Like I said, there are many ways to do this, but essentially you just need to add the cookbook's ./spec directory to rspec's $LOAD_PATH when strainer runs it. Here are a couple options:

  1. Run bundle exec rspec from inside the ${SANDBOX}/${COOKBOOK} dir.
    (RSpec automatically adds ./spec to the $LOAD_PATH, and this will probably result in the most predictable behavior that most RSpec users will be used to, as the spec run will be exactly the same as running bundle exec rspec from their cookbook's project repo, and no additional messing around with RSpec's configuration is done by Strainer that may cause it to differ from a normal run.)

  2. Add -I ${SANDBOX}/${COOKBOOK}/spec to the rspec command
    ( This can either be done by the user in their Strainerfile or by adding it to the rspec command if strainer detects it ). I've tested that this works when running strainer from a chef repo or a single cookbook repo. If done in the Strainerfile, this pushes the configuration work down to the user, which could cause frustration if a sensible recommended default Strainerfile is not provided in documentation. On the other hand, changing the command behind the user's back requires less configuration, but may not be what the user desires. Example:

    chefspec: bundle exec rspec -I $SANDBOX/$COOKBOOK/spec $SANDBOX/$COOKBOOK

  3. Create a .rspec file with -I $SANDBOX/$COOKBOOK in the directory from which you run the rspec command.
    ( This option can make it easier on the user, but if you wish to run rspec from $SANDBOX rather than $SANDBOX/$COOKBOOK, and strainer is testing multiple cookbooks, you'll have to write out this file for each separate cookbook under test. This may not be a problem, as I've only been able to run strainer test my_cookbook from a top-level chef repo, and did not find a way to run strainer on multiple cookbooks. RSpec is configured behind the user's back, which may or may not be desired, depending on the user's preference. )

  4. Set $LOAD_PATH or $: yourself and run RSpec within ruby code (similar to using RSpec::Core::RakeTask), and configure it via RSpec.configure. This option gives Strainer all the control, but would require rewriting strainer in a way that I don't think we'd want.

@sethvargo
Copy link
Contributor

Fixed in v3.1.0

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants