Rescue TypeError if a top-level class named Behavior exists

[betesh]

If your application defines a top-level class named Behavior, loading
rspec/rails/example/request_example_group.rb with Rails 3.2.22.1
results in a compiler warning:

warning: toplevel constant Behavior referenced by ActionDispatch::IntegrationTest::Behavior

This warning is the result of the situation descibed in rails/rails#6931,
i.e. Rails auto-load magic concludes that the constant named Behavior is already
defined, and tries to use it instead of attempting to auto-load a properly namespaced one.

The result is a TypeError, which can safely be swallowed.

[JonRowe]

Er no, this can't be safely swallowed, as the wrong module is now included in ActionDispatch::IntegrationTest::Behavior, they need to fix this by properly referencing the constant to fix the autoload.

[JonRowe]

Please open an issue with the rails team about this.

[betesh]

1. If ::Behavior is a class, include Behavior will raise a TypeError, which can be swallowed safely. Merging this would have resolved that case and unblocked my team and others who have a class Behavior. If ::Behavior is a module, then, as @JonRowe pointed out, "the wrong module is now included", but that behavior is unchanged in this PR. Thus, the TypeError can be swallowed safely.

2. Rails team can't fix this. As the issue I linked explains, they've escalated it to the Ruby core team, who is considering fixing it for Ruby 2.4.0.

3. The problem can be fixed in rspec-rails by not using an exception for flow control:

   if ActionPack::VERSION::MAJOR >= 5
   include ActionDispatch::IntegrationTest::Behavior
   end

If I address it this way, will you accept the PR?

[JonRowe]

1. If ::Behavior is a class, include Behavior will raise a TypeError, which can be swallowed safely. Merging this would have resolved that case and unblocked my team and others who have a class Behavior. If ::Behavior is a module, then, as @JonRowe pointed out, "the wrong module is now included", but that behavior is unchanged in this PR. Thus, the TypeError can be swallowed safely.

No it can't because the module behaviour is now not included, Ruby cannot have both a class and a module with the same name, if an error occurs expected functionality has not occured.

1. Rails team can't fix this. As the issue I linked explains, they've escalated it to the Ruby core team, who is considering fixing it for Ruby 2.4.0.

They can they can load there module properly by fully qualifying it or swallowing the exception themselves if they think it's safe, this is not a general solution but it will fix this particular case.

1. The problem can be fixed in rspec-rails by not using an exception for flow control:

if ActionPack::VERSION::MAJOR >= 5 include ActionDispatch::IntegrationTest::Behavior end

This won't fix it.

If I address it this way, will you accept the PR?

No, this should be addressed upstream, we are referencing a full qualified constant and it is producing a error based on its internals, those internals should be fixed.

[betesh]

No it can't because the module behaviour is now not included, Ruby cannot have both a class and a module with the same name, if an error occurs expected functionality has not occured.

What module behavior? In Rails 3 and 4, there is no such module.

In Rail 5, ActionDispatch::IntegrationTest is explicitly auto-loaded here, so require 'action_dispatch' should be enough to make sure the right module is included, and that's already happening as soon as you require 'rails'. The rails issue I mentioned above only occurs when the class you are trying to auto-load can be found in an autoload_path, not when it's explicitly auto-loaded.

The problem can be fixed in rspec-rails by not using an exception for flow control:

Shouldn't this be a good enough reason to fix it here even upstream changes would make it behave differently?

if ActionPack::VERSION::MAJOR >= 5

This won't fix it.

I must really be missing something here. If rspec-rails can safely swallow a NameError, that means that in Rails 3 and 4, it doesn't need this module. So why won't this fix it?

I made a mistake by linking to the Rails issue. I thought that would help by making it unnecessary to repeat what was already stated there, but it seems that instead it just gave the false impression that this is not a flaw in rspec-rails.

[myronmarston]

Using exceptions for flow control is generally a bad idea, so I'd definitely be in favor of doing a version check instead of attempting inclusion with a rescue fallback.

[JonRowe]

@betesh if you want to convert the check to an if go ahead, but it won't fix any errors caused by Behaviour being misloaded.

[myronmarston]

@betesh if you want to convert the check to an if go ahead, but it won't fix any errors caused by Behaviour being misloaded.

But it'll make rspec-rails avoid trying to load ActionDispatch::IntegrationTest::Behavior on rails versions that do not define that module. And, from what I understand about ruby constant resolution, on applications that define a Behavior class, it'll work properly on rails versions that do provide that module. Ruby constant resolution provides top-level constants when the fully qualified nested constant does not exist -- so if Behavior is returned from a ActionDispatch::IntegrationTest::Behavior reference only when ActionDispatch::IntegrationTest::Behavior does not exist.

[betesh]

Done. See #1660

Would it be possible to release this as v3.5.1, compatible with rspec v3.5.0?