3
votes

I'm following Hartl's RoR tutorial, but with updated software versions. Can you tell me how to set up the testing tools (What commands to run, and what the full contents of spec_helper should be). When I try to run RSpec from the terminal, I get a variety of errors. Fixing one error by requiring a file that StackOverflow recommends exposes another error. I'd like to create one wiki of the right way to set up Capybara + RSpec with Rails.

Gemfile:

source 'https://rubygems.org'
ruby '2.1.2'

gem 'rails', '4.1.0'

group :development, :test do
  gem 'sqlite3', '1.3.8'
  gem 'rspec-rails', '>= 3.0.0'
end

group :test do
  gem 'selenium-webdriver', '>=2.35.1'
  gem 'capybara', '>=2.4.1'
end

gem 'sass-rails', '4.0.1'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'
gem 'jquery-rails', '3.0.4'
gem 'turbolinks', '1.1.1'
gem 'jbuilder', '1.0.2'

group :doc do
  gem 'sdoc', '0.3.20', require: false
end

group :production do
  gem 'pg', '0.15.1'
  gem 'rails_12factor', '0.0.2'
end

spec/spec_helper.rb

require 'active_support'
require 'rails/all'

require 'rspec/rails'
require 'rspec/autorun'


# This file was generated by the `rails generate rspec:install` command. Conventionally, all
# specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`.
# The generated `.rspec` file contains `--require spec_helper` which will cause this
# file to always be loaded, without a need to explicitly require it in any files.
#
# Given that it is always loaded, you are encouraged to keep this file as
# light-weight as possible. Requiring heavyweight dependencies from this file
# will add to the boot time of your test suite on EVERY test run, even for an
# individual file that may not need all of that loaded. Instead, make a
# separate helper file that requires this one and then use it only in the specs
# that actually need it.
#
# The `.rspec` file also contains a few flags that are not defaults but that
# users commonly want.
#
# See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration
RSpec.configure do |config|
# The settings below are suggested to provide a good initial experience
# with RSpec, but feel free to customize to your heart's content.
=begin
  # These two settings work together to allow you to limit a spec run
  # to individual examples or groups you care about by tagging them with
  # `:focus` metadata. When nothing is tagged with `:focus`, all examples
  # get run.
  config.filter_run :focus
  config.run_all_when_everything_filtered = true

  # Many RSpec users commonly either run the entire suite or an individual
  # file, and it's useful to allow more verbose output when running an
  # individual spec file.
  if config.files_to_run.one?
    # Use the documentation formatter for detailed output,
    # unless a formatter has already been configured
    # (e.g. via a command-line flag).
    config.default_formatter = 'doc'
  end

  # Print the 10 slowest examples and example groups at the
  # end of the spec run, to help surface which specs are running
  # particularly slow.
  config.profile_examples = 10

  # Run specs in random order to surface order dependencies. If you find an
  # order dependency and want to debug it, you can fix the order by providing
  # the seed, which is printed after each run.
  #     --seed 1234
  config.order = :random

  # Seed global randomization in this process using the `--seed` CLI option.
  # Setting this allows you to use `--seed` to deterministically reproduce
  # test failures related to randomization by passing the same `--seed` value
  # as the one that triggered the failure.
  Kernel.srand config.seed

  # rspec-expectations config goes here. You can use an alternate
  # assertion/expectation library such as wrong or the stdlib/minitest
  # assertions if you prefer.
  config.expect_with :rspec do |expectations|
    # Enable only the newer, non-monkey-patching expect syntax.
    # For more details, see:
    #   - http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
    expectations.syntax = :expect
  end

  # rspec-mocks config goes here. You can use an alternate test double
  # library (such as bogus or mocha) by changing the `mock_with` option here.
  config.mock_with :rspec do |mocks|
    # Enable only the newer, non-monkey-patching expect syntax.
    # For more details, see:
    #   - http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
    mocks.syntax = :expect

    # Prevents you from mocking or stubbing a method that does not exist on
    # a real object. This is generally recommended.
    mocks.verify_partial_doubles = true
  end
=end
# require 'rails/all'
# require 'capybara/rails'
# require 'capybara/rspec'
end

Current error:

$ rspec
/home/neilsatra/.rbenv/versions/2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73: warning: loading in progress, circular require considered harmful - /home/neilsatra/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/capybara-2.4.1/lib/capybara.rb
        from /home/neilsatra/.rbenv/versions/2.1.2/bin/rspec:23:in  `<main>'
        from /home/neilsatra/.rbenv/versions/2.1.2/bin/rspec:23:in  `load'

Previous errors (so people can Google this answer):

Various errors of the form "uninitialized constant (NameError)", where something could be "ActiveSupport::Autoload", "Rails" or "ActionView::Template::Handlers::ERB::ENCODING_FLAG"

Related questions I've already looked at:

  1. Getting an unitialized constant error with RSpec. Have no idea what's causing it
  2. Rails uninitialised constant ActiveSupport::Autoload (NameError)?
2
It doesn't seem relevant to your capybara error, but you shouldn't need to require 'activesupport' or require 'rails/all' in your spec_helper.rb.Dave Schweisguth

2 Answers

1
votes

Try to put everything in one group, I think it's worth a try. like:

group :development, :test do
  gem 'rspec-rails', '>= 3.0.0'
  gem 'selenium-webdriver', '>=2.35.1'
  gem 'capybara', '>=2.4.1'
end

And this helped me out:

I put this into my spec_helper.rb

config.include Capybara::DSL

This might be an overkill but what I also did is:

spec_helper.rb:

require "capybara"

I have also encountered strange behavior when running the test right out the current directory. To fix that just move 1 directory up and run it like so:

bundle exec rspec specs/features/examples_spec.rb
1
votes

Ultimately, I couldn't get it to work even with your answer @auL5agoi, and had to resort to restarting the project with the exact gem versions prescribed by the tutorial, after which it worked flawlessly.