Added configuration to allow for custom application engine. #539

danrasband · 2012-05-10T21:25:13Z

After seeing the pull request at #471, I took it upon myself to push this along.

I've replicated the changes made in the above pull request, adding a few more changes for consistency, and also included tests.

To rehash what is in the above pull request, basically it makes it possible to run controller, mailer, requests, and routing specs when your site uses a rails engine to handle its routing. So, if you're using an engine like Spree, for example, you can add the following to your spec_helper.rb:

RSpec.configure do |config|
  config.application = MyApp::Engine
end

or, in the case of Spree:

RSpec.configure do |config|
  config.application = Spree::Core::Engine
end

Please let me know if you need any more information or if more work needs to be done.

travisbot · 2012-05-10T21:39:16Z

This pull request fails (merged 83e24bc into 0677052).

danrasband · 2012-05-11T04:14:21Z

None of the rspec tests fail for me on this one, but about half of the cucumber tests do. I tried running the cucumber tests on the unchanged master in my fork with the same result, though, so I think my changes are good.

justinko · 2012-05-11T09:34:15Z

Thanks for the pull! Tried it on Rails 3.0.12 and got this error:

/Users/justinko/code/rspec-dev/repos/rspec-rails/spec/support/engine_example.rb:9:in `<top (required)>': undefined method `routes' for RSpec::EngineExample:Class (NoMethodError)

Let me know if you have trouble setting up to test with different Rails versions.

danrasband · 2012-05-11T11:44:26Z

Ah, that makes sense. This was my first pull request ever And I'm still pretty new to rails, so I didn't even think of testing across multiple versions of rails. My guess is that I'll somehow have to write version-specific code for rack applications. Is that an accepted practice for gems?

justinko · 2012-05-13T05:35:18Z

Should be pretty simple to support Rails 3.0.x. You'll have to dig in and find the differences - you can do Rails.version to get the Rails version. I'd like to make it very explicit that "this code is for Rails 3.0.x" instead of just using a respond_to? or something - so we know to remove it when the time comes.

This commit adds Rails version checking to the RSpec application configuration to handle Rails 3.0.x. The Rails::Engine class, while available in Rails 3.0, does not have the capability to draw routes as it does in 3.1 and above.

travisbot · 2012-05-16T20:04:42Z

This pull request passes (merged acd46c2 into 0677052).

justinko · 2012-05-17T06:03:57Z

Just to be clear, this feature will not work on Rails 3.0.x?

justinko · 2012-05-17T06:34:42Z

lib/rspec/rails/engine_support.rb

Let's change this file name (and module name) to "application" - it really has nothing to do with "engines".

Also, let's always load this file (I know I said not to in a previous comment). We can then override the writer method to raise an error if it's not supported:

RSpec.configuration.add_setting :application, :default => ::Rails.application unless rails_3_0? def Rails.configuration.application=(*) raise "Setting the application is only support on Rails 3.1 and above" end end

Should I add the override method to the application support file (I have now changed it to application.rb)?

It seems like you can't override a method this way, because I'm getting this error:

rspec-rails/lib/rspec/rails/application.rb:7: syntax error, unexpected '.', expecting ';' or '\n' (SyntaxError) def Rails.configuration.application=(*)

It doesn't seem to like this form of overriding...

justinko · 2012-05-17T06:42:46Z

BTW, thanks for your patience! I know we'll emerge with some clean code :)

danrasband · 2012-05-17T14:20:42Z

Thank you for reviewing all of my code!!! All of your suggestions are extremely helpful. I'll work on implementing them as soon as I can.

And yes, I'm pretty sure that we'd have to make the application configuration option only available for Rails 3.1+.

zamith · 2012-05-25T21:28:53Z

I solved this problem with

before(:each) { @routes = MyApp::Engine.routes }

which I don't feel is really nice, would love to have this pulled and documented, since I found it hard to get working.

Keep up the good work. ;)

danrasband · 2012-05-30T19:05:52Z

Unfortunately I found some bugs with the most recent commit (acd46c2). Using the configuration option makes some controller tests fail. I'll do some more research when I have the time to figure out what's going on.

danrasband · 2012-06-01T22:14:43Z

I've gotten everything working (and tests passing) except for one thing: overriding the RSpec.configuration.application= method. I also opted to name the method for determining rails version compatibility as follows:

at_least_rails_3_1?

I put this method in lib/rspec/rails.rb as a global method, but I'm not sure if this is a good idea:

# ... some code ...

# METHOD TO BE ADDED HERE
def at_least_rails_3_1?
  Gem::Version.new(Rails.version) >= Gem::Version.new('3.1.0')
end

require 'rspec/rails/extensions'
# ... some more code ...

Any suggestions?

justinko · 2012-06-02T04:56:04Z

@danrasband can you push the code please?

This commit removes most if-statements from the example groups, consolidating to a global method called `at_least_rails_3_1`. It also adds filters to the rspec tests and changes engine_support.rb to application.rb.

travisbot · 2012-06-06T15:29:11Z

This pull request passes (merged 1c451f8 into 0677052).

justinko · 2012-06-06T19:00:16Z

I've gotten everything working (and tests passing) except for one thing: overriding the RSpec.configuration.application= method.

What problem is it giving you? Looks like your implementation should work.

Adds an override of Rails.configuration.application=(*) setter to raise an error when Rails.configuration.application is set in Rails 3.0. Also moves at_least_rails_3_1? method to the RSpec::Rails module as a public module method.

danrasband · 2012-06-22T15:41:06Z

I got everything working now (I think). Thanks for all the help!

travisbot · 2012-06-22T16:17:27Z

This pull request passes (merged b694543 into 0677052).

justinko · 2012-06-22T17:43:39Z

Awesome! Going to merge this in a bit.

Added configuration to allow for custom application engine.

dchelimsky · 2012-06-26T10:47:14Z

lib/rspec/rails/application.rb

@danrasband @justinko Does this need to happen via RSpec config? Any reason not to just set Rails.application = xxx?

@dchelimsky Side note: the implementation of this feature on master is drastically simpler.

@danrasband Can you please confirm @dchelimsky's question? Thanks.

I saw the implementation and agree it's clean - my issue is that this is not really an RSpec concern - it's a Rails concern.

@dchelimsky I don't really know the answer to your question. I'll try to do some experimentation, and if doing Rails.application = xxx works and doesn't have unintended side effects, then I think that may be the way to go.

I'm planning to release 2.11 this weekend, but I don't want to include this as/is. @danrasband - will you have time to look at this before then?

I should be able to look at this today or tomorrow.

- not ready for release so backing out - changes are stored in engine-support branch

dchelimsky · 2012-07-07T20:39:30Z

I branched off master to the engine-support branch and then backed out these changes on master for the 2.11 release. We can revisit for the next release.

jfirebaugh · 2012-12-08T03:02:54Z

Should this be reopened? It seems like it's still an issue in 2.12.

alindeman · 2012-12-08T03:06:23Z

@jfirebaugh, you mean the code here didn't actually fix the issue?

jfirebaugh · 2012-12-08T03:14:54Z

From my reading of the comments, the changes got backed out in 2.11, to be revisited for 2.12. Did it actually get reinstated in 2.12?

alindeman · 2012-12-08T03:16:15Z

Oh. Right. Let me restore my context on this (might be Sunday or Monday) and get back to you.

alindeman · 2012-12-28T17:55:12Z

As far as I can tell, setting ::Rails.application = MyEngine::Engine (e.g., in spec_helper.rb) removes the need to use the use_route option (described in the Testing Rails Engines guide) in controller specs.

Does this work for everyone?

/cc: @jfirebaugh, @danrasband

jfirebaugh · 2012-12-28T18:50:15Z

No, that doesn't work. My specs fail with all sorts of errors, most prominently:

ActionView::Template::Error: undefined method `assets' for #<Rails::Engine::Configuration:0x007f7f9a27b5e8>

I'm pretty sure that for engine tests, a full dummy application is needed.

jfirebaugh · 2012-12-28T18:52:27Z

BTW, I'm coming here from rails/rails#4364, if that context helps.

alindeman · 2012-12-28T18:56:11Z

Good point. I hadn't tried a view spec.

Given that the Rails guides themselves recommend the use_route option, I am inclined (at this point) to leave routing as-is. What do you think?

alindeman · 2012-12-28T18:57:53Z

BTW, I'm coming here from rails/rails#4364, if that context helps.

Whoops, saw this after my previous comment.

This does help a bit. I probably need to spin up a Rails application that fully demonstrates the problem to poke around. I've added this to my list, but if you have time, feel free to do so and push it up to GitHub.

Exoth · 2013-01-08T10:05:57Z

It would be nice to have it added in the next version as starting from version 2.12.1 this good old hack stopped working for routing specs:

before { @routes = CmsEngine::Engine.routes }

Now I need to do:

before do
  @routes = CmsEngine::Engine.routes
  assertion_instance.instance_variable_set(:@routes, CmsEngine::Engine.routes)
end

Which is quite clumsy.

jcoyne · 2013-01-09T19:00:35Z

I also have the same use-case / complaint as @Exoth. Can we have a simple way to test our engine routes?

alindeman · 2013-01-12T18:49:04Z

It would be nice to have it added in the next version as starting from version 2.12.1 this good old hack stopped working for routing specs

2.12.2 will be released soon with the relevant code reverted. We should figure out a better way to expose the engine's routes, but I'm not sure what that will look like yet.

Added configuration to allow for custom application engine.

83e24bc

Make code version specific for rails 3.1 and up

acd46c2

This commit adds Rails version checking to the RSpec application configuration to handle Rails 3.0.x. The Rails::Engine class, while available in Rails 3.0, does not have the capability to draw routes as it does in 3.1 and above.

justinko reviewed May 17, 2012
View reviewed changes

alindeman mentioned this pull request Jun 2, 2012

Added 'application' configuration setting to set a Rack app to allow changing routes in controller specs #471

Closed

Tweak alternate app integration

1c451f8

This commit removes most if-statements from the example groups, consolidating to a global method called `at_least_rails_3_1`. It also adds filters to the rspec tests and changes engine_support.rb to application.rb.

Raise error for Rails 3.0

b694543

Adds an override of Rails.configuration.application=(*) setter to raise an error when Rails.configuration.application is set in Rails 3.0. Also moves at_least_rails_3_1? method to the RSpec::Rails module as a public module method.

justinko added a commit that referenced this pull request Jun 23, 2012

Merge pull request #539 from danrasband/custom-application-configuration

248ce66

Added configuration to allow for custom application engine.

justinko merged commit 248ce66 into rspec:master Jun 23, 2012

dchelimsky reviewed Jun 26, 2012
View reviewed changes

dchelimsky added a commit that referenced this pull request Jul 7, 2012

revert all changes for #539

603cf3d

- not ready for release so backing out - changes are stored in engine-support branch

drogus mentioned this pull request Sep 14, 2012

Tests failing for helpers (and possibly views) when run within a mountable engine. rails/rails#4364

Closed

jfirebaugh mentioned this pull request Dec 4, 2012

Path to konacha iframe is wrong when mounted as an engine jfirebaugh/konacha#85

Closed

Uh oh!

Added configuration to allow for custom application engine. #539

Added configuration to allow for custom application engine. #539

Uh oh!

Conversation

danrasband commented May 10, 2012

Uh oh!

travisbot commented May 10, 2012

Uh oh!

danrasband commented May 11, 2012

Uh oh!

justinko commented May 11, 2012

Uh oh!

danrasband commented May 11, 2012

Uh oh!

justinko commented May 13, 2012

Uh oh!

travisbot commented May 16, 2012

Uh oh!

justinko commented May 17, 2012

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

justinko commented May 17, 2012

Uh oh!

danrasband commented May 17, 2012

Uh oh!

zamith commented May 25, 2012

Uh oh!

danrasband commented May 30, 2012

Uh oh!

danrasband commented Jun 1, 2012

Uh oh!

justinko commented Jun 2, 2012

Uh oh!

travisbot commented Jun 6, 2012

Uh oh!

justinko commented Jun 6, 2012

Uh oh!

danrasband commented Jun 22, 2012

Uh oh!

travisbot commented Jun 22, 2012

Uh oh!

justinko commented Jun 22, 2012

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dchelimsky commented Jul 7, 2012

Uh oh!

jfirebaugh commented Dec 8, 2012

Uh oh!

alindeman commented Dec 8, 2012

Uh oh!

jfirebaugh commented Dec 8, 2012

Uh oh!

alindeman commented Dec 8, 2012

Uh oh!

alindeman commented Dec 28, 2012

Uh oh!

jfirebaugh commented Dec 28, 2012

Uh oh!

jfirebaugh commented Dec 28, 2012

Uh oh!

alindeman commented Dec 28, 2012

Uh oh!

alindeman commented Dec 28, 2012

Uh oh!

Exoth commented Jan 8, 2013