Fixes evergreen/rails to work out of the box in an engine. #30

Closed
wants to merge 1 commit into
from

5 participants

@whilefalse

In an engine, the normal behaviour is to place your tests in
spec/javascripts or test/javascripts.

However, when the app is booted, the dummy app in spec/dummy or
test/dummy is booted, so Rails.root returns /spec/dummy.

In this case, we want evergreen to look at , so we go up
two levels from the Rails.root.

I've also added some tests for the rails.rb file, as there were none
before, and tests for this new functionality. Unfortunately it requires
rails to be a development dependency since we make use of Rails::Engine
and Rails::Application in the tests.

I couldn't find a better way to check if we're in an engine's dummy app
than to look at the #engine_name - this is not great but there is no
other way I could find.

Also, I couldn't get the entire test suite to pass after a fresh
checkout, so I'm not sure if this affects anything else.

@whilefalse whilefalse Fixes evergreen/rails to work out of the box in an engine.
In an engine, the normal behaviour is to place your tests in
spec/javascripts or test/javascripts.

However, when the app is booted, the dummy app in spec/dummy or
test/dummy is booted, so Rails.root returns <engine_path>/spec/dummy.

In this case, we want evergreen to look at <engine_path>, so we go up
two levels from the Rails.root.

I've also added some tests for the rails.rb file, as there were none
before, and tests for this new functionality. Unfortunately it requires
rails to be a development dependency since we make use of Rails::Engine
and Rails::Application in the tests.

I couldn't find a better way to check if we're in an engine's dummy app
than to look at the #engine_name - this is not great but there is no
other way I could find.

Also, I couldn't get the entire test suite to pass after a fresh
checkout, so I'm not sure if this affects anything else.
91f3cd5
@jnicklas
Collaborator

While it would be good to fix this problem, this is not the right fix imo. We're hardcoding a lot of behaviour here. Who says that this directory structure is going to stay the same? Who says that the name of the dummy application will stay the same?

@whilefalse

I agree with you about the dummy application name - that is a sucky way to check if we are in an engine's dummy app. We need a method in Rails to tell us whether the app is an engine's dummy application or not.

But if you're developing with a generated engine, the dummy app has that name and has no reason to change, and the directory structure is a standard one.

If you are developing an engine with a non-standard directory structure, you can always add an initializer to override the default behaviour. I think it makes sense to have the common 90% of cases work and for the 10% to have to reconfigure, rather than require everyone using engines to add configuration to make it work. This is convention over configuration in my opinion as engines are setup this way by default.

Of course, your project so feel free to shoot me down :) Do you have any other ideas how this could be implemented? As far as I could see we'd need some new Rails functionality to get it to work in a neater way.

Thanks.

@abepetrillo
Owner

+1

@jorgegorka

Whilefalse is right this is a much needed functionality and it's convention over configuration after all !!

@jhilden

I have hit the same problem, trying to test the JS of my Rails:Engine gem.

So far I'm just compiling the assets in the dummy app with rake assets:precompile and then run evergreen with this setting config.public_dir = 'test/dummy/public/assets/' (see https://github.com/jhilden/i18n_viz), but I would be very interested in a better setup. Has anybody figured something out yet?

@abepetrillo
Owner

Closing this pull request, as it needs rebasing and is over two years old :)

@abepetrillo
Owner

Just coming back to this now myself, jhildan's work around works for me, but definately on the cards to fix evergreen when using an engine.

@jhilden Did you ever get bundle exec evergreen serve working? Or did you simply rely on bundle exec evergreen run

@jhilden

Sorry, I'm not actively working on those specs anymore and have been using jasminerice + guard-jasmine for recent projects.

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