exception when running all specs #598

brewster1134 opened this Issue Aug 18, 2012 · 11 comments


None yet
5 participants

I created a spec to test methods in my ApplicationHelper module but ran into a strange exception when running rspec on my entire spec folder. the specs pass if i run application_helper_spec.rb on its own. I tried removing config.order = 'random' thinking that might be the cause but it gives the same results. when running all my tests, for some reason only this helper fails with this exception. the other tests pass fine. im pretty stumped.

rspec-rails 2.11.0
rails 3.2.8 (also tried 3.2.7)

# spec/spec_helper.rb
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'spork'

Spork.prefork do
  require 'capybara/rails'
  require 'capybara/rspec'
  require 'rspec/autorun'
  require 'rspec/rails'
  require 'rubygems'
  Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

  RSpec.configure do |config|
    config.include Mongoid::Matchers, :type => :model
    config.include Devise::TestHelpers, :type => :controller
    config.infer_base_class_for_anonymous_controllers = false
    config.order = "random"

    config.before :suite do
      DatabaseCleaner[:mongoid].strategy = :truncation

    config.before :each do

    config.after :each do

Spork.each_run do
# spec/helpers/application_helper_spec.rb
require 'spec_helper'
describe ApplicationHelper do
  it 'should do something' do
# spec results

Running all specs
Running tests with args ["--drb", "-f", "progress", "-r", "/Users/brewster/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/guard-rspec-1.2.1/lib/guard/rspec/formatters/notification_rspec.rb", "-f", "Guard::RSpec::Formatter::NotificationRSpec", "--out", "/dev/null", "--failure-exit-code", "2", "spec"]...


  1) ApplicationHelper should do something
     Failure/Error: Unable to find matching line from backtrace
       stack level too deep
     # /Users/brewster/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/routing/url_for.rb:102

Finished in 0.65474 seconds
71 examples, 1 failure

Failed examples:

rspec ./spec/helpers/application_helper_spec.rb:4 # ApplicationHelper should do something

Randomized with seed 59900

Exception encountered: #<SystemStackError: stack level too deep>

dchelimsky commented Aug 18, 2012

How are you invoking rspec?

normally i use guard bundle exec guard

but for the sake of troubleshooting this error i am invoking rspec directly

bundle exec rspec spec/ causes the error.
bundle exec rspec spec/helpers/application_helper_spec.rb works fine and all tests pass.


alindeman commented Aug 20, 2012

Do any of your other specs mock or stub on any_instance? If you comment out or pending those specs, does the full suite run green?

nope. no use of any_instance. didn't even know about that method!


alindeman commented Aug 20, 2012

Cool: just wanted to rule out rspec/rspec-mocks#167

I have been seeing the same thing.
After some poking around I found this.
While the error is not occurring in the same place in Rails. (layouts.rb:359 vs url_for.rb:102)
I checked anyway, and I did find a call to "include Rails.application.routes.url_helpers" outside a describe block..
Once moved inside my whole spec suite is now running again.


patmaddox commented Sep 11, 2012

I'd look at simplifying the rspec invokation a bit...there are a couple things I see that might be getting in the way of actual information (because that's the least informative error message ever :)

  • get rid of --drb option
  • ditch the -r flag to guard notification and the -f for guard formatter. We want to eliminate guard here (plus I think you're no longer loading the rest of it)
  • ditch the "--out", "/dev/null" flag - there might be informative output that is currently being sent to /dev/null

It might be tough for us to debug this remotely like this unless someone happens to have come across this exact problem...but simplifying the runner execution as much as possible might provide more information to get past this.


patmaddox commented Sep 11, 2012

@brewster1134 did you see the stack overflow thread and possible solution that @impurist linked to?


alindeman commented Sep 28, 2012

Any news @brewster1134? I'd definitely like to help figure this out, and boiling it down to the simplest example that still demonstrates the problem is likely going to be required.

Gah! Sorry, this has been off my radar lately. But I just tried the link suggested by @impurist and it indeed worked!


alindeman commented Sep 28, 2012

Awesome! Thanks for looping back on it @brewster1134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment