Rspec-rails: wrong host for url helpers in feature specs

[anujbiyani]

In a bunch of my feature specs, when I call *_url helpers the host is "www.example.com" instead of what I've configured. I noticed that https://github.com/rspec/rspec-rails/blob/master/lib/rspec/rails/example/feature_example_group.rb#L9 hardcodes the default host and there doesn't seem to be a way to change it.

If I monkey-patch the constant to what I want, then the *_url helpers give me the correct host.

Is there a reason why FeatureExampleGroup::DEFAULT_HOST isn't configurable?

[cupakromer]

It's not hard coded, RSpec defines that constant in case a user specific one hasn't been set. We check for that here: https://github.com/rspec/rspec-rails/blob/master/lib/rspec/rails/example/feature_example_group.rb#L18

In general, path helpers are preferred local app ones to use in the specs. Be aware that Capybara (which is used for feature specs) has it's own URL setting: https://github.com/jnicklas/capybara#calling-remote-servers

[anujbiyani]

Hmm not sure how I missed that. I've tried setting default_url_options[:host], though, and it keeps coming up as nil.

I've set default_url_options inside ApplicationController (and it works when I call *_url helpers in controllers/views/etc), and in the spec itself (e.g. Rails.application.routes.default_url_options[:host] = 'www.foo.com', but every time I check default_url_options[:host] inside of feature_example_group.rb it comes up as nil.

I also have Capybara.app_host defined.

[cupakromer]

Thanks for the reply. I'm not sure this is an RSpec issue just yet, but I think this warrants another look on my end. Can you share your Rails, Ruby, and RSpec versions so I can look this more?

[anujbiyani]

rails 4.0.9
rspec-rails 3.0.2
ruby 2.1.2-p95
capybara 2.4.1

I also just tried rspec-rails 3.1.0 with the same results.

Thanks for looking into it!

[JonRowe]

Are you sure your setting the options correctly for the environment you're running, and are you using rack-test or something else, if capybara starts a server it forks the process so you need to have set the options before that happens.

[anujbiyani]

As far as I can tell I'm setting everything correctly for the test environment. I'm not using rack-test. I'll check if the Capybara fork has the right settings; that could be the issue. Thanks for the lead!

Separately, I haven't figured out the root of the problem yet but I did find a monkey patch in my codebase that was confusing things. I'm confident this is not an RSpec issue, but it still has me stumped.

Appreciate the help! I'll go to a more general audience (i.e. SO) if I need further help as this seems to be specific to my application.

[iainbeeston]

I'm experiencing this issue as well.

I'm testing a page using capybara. I have a form input that is pre populated with a url, and I have an expectation that the value of this input should match the one returned by a rail url helper (eg. expect(input.value).to eq(users_url)).

I've changed the default host used by capybara, and the default url opts rails. The value generated (by rails) for the input has the correct host. But unfortunately the value in my spec that I'm testing it against (eg. users_url) has the host set to www.example.com, instead of the one that rails is using.

Delving into the code (at runtime) for the feature example group, no matter what I do I can never get it to find the default_url_options that I've set in rails (should this be coming from routes.url_helpers? Or routes.mounted_url_helpers?). Interestingly, the code for mailer example group explicitly merges in
Rails.configuration.action_mailer.default_url_options (but feature example group does nothing similar).

Can we reopen this issue? I'd be glad to help track down the cause

[iainbeeston]

If, in my spec, I directly access the rails url helper (eg. Rails.application.routes.url_helpers.users_url) I get a url with the correct host (whereas if I just rely on the version in the feature example group it has the incorrect host)

[lime]

Note to others who encounter this: #1275 discusses the same problem, and is still open at the time of writing.