-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot access ApplicationHelper #523
Comments
@abacha, i tried to reproduce your case but i didn't have success. Here are all the codes that i used: Gemfile:
Resource:
Application helper:
Decorator:
Console test:
Maybe you are doing something else in your code that is affecting this behavior, could you show more information about your method or configs? |
I don't know what it was, I cleaned up my changes and reapplied it and now it works |
nice! 😉 |
Hi there! This is happening to me now and then at our jenkins build, and on production, too. Now I am able to reproduce it always (by replaying our specs with the same --seed), so I'll try to get more information. Basically, in the sometimes failing spec:
I am using version 1.2.1 of Draper, with default It's really weird,
always works, but
fails sometimes at decorators' specs!! I'll get in touch again when i have more info... |
Strange. Yes, please let me know; if you get a way to reproduce, i'll re-open. |
Ok, I think I've found something: Here at
When it fails,
When it works, it's something like:
So it looks that somehow draper swaps the correct controller and uses my Since I'll now try to find out why this is happening... |
Ok, I think I know what's happening: I see that it's normal sometimes that view_context has as a controller a Mailer instead of one ApplicationController. The thing is, In
Now, in some of my After this model spec, one decorator spec comes and Draper::ViewContext.current is pointing to that mailer's view_context because it has not been reset. This fixes it:
but I don't know if this is OK, or something else should be tried. Probably that is what's happening also to us in production. But there this would not do anything, and i don't know that the right fix should be. Any thoughts? Btw, thanks a lot for Draper, it's great to be able to get rid of untested/hard to use helpers :) |
Hmm. We should be clearing it: https://github.com/drapergem/draper/blob/master/lib/draper/test/rspec_integration.rb#L12 |
Maybe this way would be better:
|
How is that different? My eyes can't see the diff. Actually, how about this: submit it as a PR. :) That way we can make sure it's working for you. |
Is different because it will not call |
Done! It passes the tests. |
By doing it before, we get sure that another type of spec (model, acceptance) does not leave ViewContext in a wrong context... drapergem#523
This is randomly and mysteriously happening to me on a project now as well. I'm also getting the ViewContext to be set to a mailer somehow (although running rspec spec/decorators/blah and rspec spec does not cause any difference). Calling Draper::ViewContext.clear! from within pry right before the problematic line makes it work. Adding a before(:each) do / Draper::ViewContext.clear! / end does not fix the problem though. Any suggestions? I'm pretty lost at this point. :( |
I have this issue on a recent project (draper 1.4.0, rspec 3.1.0). class Post < ActiveRecord::Base
belongs_to :user
# ...
end class PostDecorator < Draper::Decorator
delegate_all
def post_test
helpers.application_test
end
end module ApplicationHelper
def application_test
1
end
end FactoryGirl.define do
factory :post do
association :user
# ...
end
end # ...
RSpec.describe PostDecorator, type: :decorator do
subject(:post) { build(:post).decorate }
it 'calls application helper' do
expect(post.post_test).to eq 1
end
# ...
end User is set with a subject(:post) { build(:post, user: build_stubbed(:user)).decorate } Make the tests pass. EDIT: Running this single test also failed, so I never suspected about the |
@leonelgalan probably the email is causing some issue that prevents the post to be created correctly. Can you give us more details about the failed test? How is the state of the post and the decorator object before the expectation happens? |
Hello Carlos, the post is created successfuly, valid with no errors and the error is the following:
Adding Draper::ViewContext.current.class_eval do
include ApplicationHelper # workaround for draper test bug
end to the ApplicationHelper method makes the test pass. |
I had the same problem. In a project I work on, we are using a decorator within a model method (don't ask me why). The problem occurs when certain mailer specs (which do not use ApplicationHelper) are run before this model's spec. Adding @gaizka solution in #547 does not fix this problem, since the view context is set to the mailers view context without application helper, while it should be reset before the model spec (or after the mailer spec). Maybe we should run |
It is still not clear how to deal with this problem. We are facing the issue that once the mailer specs run, the controller specs are failing precisely because of this. Draper should be automatically configured so that it clears any cached variables after each spec. If someone wants to optimize the speed of the specs by enabling that, they should have the option, but at their own risk! I am trying to make it work by adding this to my spec_helper.rb:
But it still does not work EDIT adding the after hook made it work now:
|
I just added |
I've recently updated Draper to 1.2.0 but now I can't access ApplicationHelper methods
rails 3.2.11
draper 1.2.0
The text was updated successfully, but these errors were encountered: