Allow the set the controller spec routes globally.

[tvdeyen]

For testing controllers in an rails engine one can set the engine routes inside the controller spec file:

https://www.relishapp.com/rspec/rspec-rails/v/3-1/docs/controller-specs/engine-routes-for-controllers

Great, but it is very tedious to set this in every single controller spec. Especially for large rails engines, like spree or alchemy.

It would be great if one could set the routes globally like this:

# spec_helper.rb
RSpec.configure do |config|
  config.before(:each) do
    # Load the routes for controller specs
    if example.metadata[:type] == :controller
      example.routes { Alchemy::Engine.routes }
    end
  end
end

[cupakromer]

This appears to be a duplicate of #1203. As posted in that issue you can do this already on your own and it's only about 2 lines of code.

I'm relatively opposed to a global configuration option which stamps on the default rails routes. That would affect all spec types, additionally it would be much harder to track down where this may have occurred when it happens unexpectedly.

Cross posting the code sample:

module MyEngine
  module RSpec
    module ControllerRoutes
      extend ActiveSupport::Concern
      included do
        routes { ::MyEngine::Engine.routes }
      end
    end
  end
end

RSpec.configure do |c|
  c.include MyEngine::RSpec::ControllerRoutes, type: :controller
end

Is there something about your case which I am missing?

[tvdeyen]

Thanks @cupakromer and sorry that I didn't saw #1203 in the first place.

Unfortunately your proposed solution doesn't work. Although most controller specs now pass, some specs, mostly regarding put and delete requests still fail. The other specs that fail are specs using routes of the dummy app and not routes of the engine I am testing.

I also tried the fixes @huoxito made for spree, but still the same specs fail. So, since I test Rails 4.2 beta I can't tell for sure if this is rspec related or Rails 4.2 related. Hope to find some time to test this against Rails 4.1 and then report if this will work or not.

Anyway your solution would only work for engines always testing their own routes. But sometimes you want to test the integration of the dummy into your engine and vice versa. Therefore you need to use the routes of the dummy app. Rails has a very neat way to handle routes of engines and of the host app the engines are mounted at. You can call routes on main_app.my_host_app_url or your engine my_engine.my_engine_url routing proxy objects. It would be nice to have something like this in rspec.

[huoxito]

But sometimes you want to test the integration of the dummy into your engine and vice versa.

@tvdeyen curious about what you mean, isn't that supposed to be covered by integration acceptance specs? controller specs are meant to only reach the endpoint concerning that particular controller. Could you elaborate a bit on why you would test the dummy app routes inside your engine? Would appreciate any examples.

[tvdeyen]

@huoxito Yes. Think of an resourceful engine like rails_admin. You surely want to test the integration of your dummy app in that engine. Alchemy CMS also has this kind of rails admin functionality where your app (dummy app in the case of specs) can inherit from a resources controller provided by the engine and then get CRUD functionality for your controller.

Have a look into this spec of alchemy to see what I mean: https://github.com/magiclabs/alchemy_cms/blob/master/spec/controllers/admin/resources_controller_spec.rb

Maybe there is a better solution for that particular need, but it all worked great before Rails 4.2 stroke with breaking changes.

[JonRowe]

Unfortunately your proposed solution doesn't work. Although most controller specs now pass, some specs, mostly regarding put and delete requests still fail.

Can you reproduce that for us, @cupakromer's suggestion shouldn't cause that behaviour it might be a bug.

The other specs that fail are specs using routes of the dummy app and not routes of the engine I am testing.

Tag the specs appropriately so the routes only get mixed into the specs you care about, or re-override the routes, incidentally this is exactly why a global config value would be a bad idea, it would stomp on these too.

Rails has a very neat way to handle routes of engines and of the host app the engines are mounted at. You can call routes on main_app.my_host_app_url or your engine my_engine.my_engine_url routing proxy objects.

Are these are available in minitest? Or just in app code?

[tvdeyen]

Can you reproduce that for us, @cupakromer's suggestion shouldn't cause that behaviour it might be a bug.

I try to reproduce this in a stable rails app. Like I said I can't tell if this is Rails 4.2beta related.

Tag the specs appropriately so the routes only get mixed into the specs you care about, or re-override the routes, incidentally this is exactly why a global config value would be a bad idea, it would stomp on these too.

Great idea. Will try that. And yes I am totally with you that a global config would be a bad idea. The best solution IMO would be to provide some kind of route proxy object I can call routes on. One for the engine and one for the dummy app (or rails app). The rails app routes should be the default object rspec uses and engine developers would use their optionally routing object.

Something like:

# in my engine
it "does" do
  my_engine.get :index
  expect(something).to happen
end

vs.

# in a normal rails app
it "does" do
  get :index
  expect(something).to happen
end

Are these are available in minitest? Or just in app code?

AFAICT they are only available in app code. But can't tell for sure.

[cupakromer]

I try to reproduce this in a stable rails app. Like I said I can't tell if this is Rails 4.2beta related.

I doubt it, but it is a possibility. Why not setup a Rails 4.2beta sample app to reproduce?

engine developers would use their optionally routing object

You should already be able to do that. As per your linked example you should be able to pass a :use_route option with the params hash:

get :index, use_route: :my_engine
get :show, id: '1', use_route: :my_engine

Are these are available in minitest? Or just in app code?

AFAICT they are only available in app code. But can't tell for sure.

If they are available in minitest they should be available for RSpec in most cases too. From the quick search I did it looks like they aren't available outside of app code by default.

[huoxito]

hey guys just for the record I think it's highly recommended to move away from :use_routes option at this point because it doesn't really work the way it's documented right now (see the rails PR linked here).

[cupakromer]

@huoxito I think you forgot the PR link

[tvdeyen]

@cupakromer

You should already be able to do that. As per your linked example you should be able to pass a :use_route option with the params hash:

Yes, we are actually doing that a already. But unfortunately Rails drops this in 4.2. And like @huoxito said, it's never been recommended way.

For further informations, please have a look at the discussion at this Rails pull request.

[jfelchner]

Now that Rails 4.2 is released, I'm getting these deprecation warnings like crazy.

I honestly don't feel like it's a big deal to add:

routes { MyEngine::Engine.routes }

to the top of each controller spec. But I can see why someone like Spree wouldn't want to do that for every one of their hundreds of spec files.

I would like to know if there's any traction on the solution though because I'd rather not do it the above way and then have a "blessed" RSpec way of doing it and have to change it a second time.

[jfelchner]

Yeah, spoke too soon. That line above, although in the Relish docs, doesn't actually work.

[cupakromer]

@jfelchner can you specify what didn't work and the error you get? I just checked with Rails 4.2 and that line does work in a controller spec for me.