Document clearly what to do in the face of configuration option warning. #455

Closed
dchelimsky opened this Issue Sep 9, 2011 · 13 comments

Projects

None yet

4 participants

@dchelimsky
RSpec member
@dchelimsky
RSpec member
@elight
@dchelimsky
RSpec member
@elight
@dchelimsky
RSpec member
@pda

A more subtle example than two different configurations would be a suite with a single RSpec configuration, but containing some isolated tests; no spec_helper == no Rails startup time penalty.

The isolated tests don't care if/how RSpec is configured, but if they're loaded before the spec_helper-dependent tests, the suite crashes.

This is particularly nasty because it's dependent on ordering; rspec rails_spec.rb isolated_spec.rb works fine, but rspec isolated_spec.rb rails_spec.rb errors.

I've been running such a suite for quite some time, and have watched as it began to trigger deprecation warnings in RSpec 2.6, and now dies completely in RSpec 2.7. This is frustrating; I know the suite is fine, there's no configuration conflicts that I need to be protected from by warnings/errors.

By the looks of it, f46e00a makes the error much more selective, only triggered by setting mock_framework and expect_with, but that still means the default config.mock_with :rspec triggers the error.

So, is it really necessary to so actively enforce this policy?

@myronmarston
RSpec member

So, is it really necessary to so actively enforce this policy?

Well, people were getting random, hard-to-explain SystemStackErrors. I've spent about 40 hours of my time trying to figure out the best solution to work around a ruby 1.9 bug and this is like my 3rd or 4th attempt. Sorry it's causing pain for you :(.

Believe me, I'm annoyed that this bug exists in 1.9 and I have to put in a crappy work around like this. What would you suggest as a better solution? I don't consider letting end users get SystemStackError to be a viable option.

Anyhow, in your case, just remove config.mock_with :rspec. It's unnecessary as it just configures RSpec to do what it would do anyway. Then things should work fine, I think.

BTW, I reported the bug in ruby 1.9 to the ruby issue tracker but no one has taken a look at it yet, apparently. Please comment there if you want to see this bug addressed in ruby.

@myronmarston
RSpec member

@pda: I just realized that this thread doesn't really give you the full history of how this warning and error came about. Read this--it explains the original issue and the attempts I've made to deal with it.

As always, we're open to suggestions for how to better handle it.

@pda

Thanks for the link, Myron, that thread / comment makes it much clearer.

What are your thoughts on removing mock_with :rspec from the default spec_helper so that less people run into this problem?

I've chimed in on that Ruby 1.9 bug and am trying to solicit some support on Twitter.

Cheers!
Paul

@myronmarston
RSpec member

Hey Paul,

Thanks for trying to bring attention to the ruby bug! And your PR to rspec-rails to remove the unnecessary default config is great, too. One additional thing we can do to help for a case like yours is to not raise an error when the config is a no-op. I've opened an issue for this.

Myron

@myronmarston
RSpec member

I'm going to close this as it is quite old, and since the fix in #490 (and since blogging about it), I haven't heard any more issues people have had with this.

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