I feel like I'm missing something pretty basic, but I can't seem to figure it out, either.
When doing the following spec:
require 'spec_helper'
describe "/mymodel/show.html.erb" do
before(:each) do
#mymodel = Factory(:mymodel)
#user = Factory(:user)
assign(:web_tip, #mymodel)
assign(:current_user, #user)
end
it "renders attributes in <p>" do
render
rendered.should have_text(/somevalue/)
end
end
I get an error that the local variable current_user is undefined (the view's layout wants to call it to show the current login status).
I'm on Rails 3, Rspec 2.6.4, and thought I was following the current docs correctly.
This one is old, but for the sake of Google:
assign only creates instance variables. However, current_user is a helper method (or a local variable). Assuming you're not entirely relying on view testing, you can use the following before block to make it work:
before(:each) do
view.stub(:current_user) { User.new }
end
what worked for me (with a similar problem) was something like:
#controller.stub(:current_user) { #user }
I think the problem is that current user is not an assignation (instance variable), is a value in the session.
Hope it helps
Well, I never figured out how to get authlogic to work with this, so I monkeypatched a current_user method on the tests themselves to get it to work.
def current_user
Factory(:user)
end
Worked, though I'd still award an "answer" if someone can help me to di the right way.
Related
The simplest way to write specs checking that a controller is authorizing the signed-in current_user to use the said action is to explicitly write two specs checking that a user with permission can run that action, and another cannot. For example:
# The controller action:
def some_action
authorize! :do_this_action, #some_object
end
# The spec:
it "should work when authorized" do
sign_in #user
get :some_action
response.should be_success
end
it "should not work when not authorized" do
sign_in #other_user
get :some_action
response.should_not be_success
end
But this is not great, as it requires a great amount of code (two or more specs) and doesn't actually test directly that the authorization is being checked (do_this_action in the example).
I would like to be able to write a simpler spec, e.g. (an example using 'rr' for mocking)
it "should check the user can do_this_action" do
mock(controller).authorize!(:do_this_action, some_object)
get :some_action
end
I think this would be shorter and directly test that the authorization check I want to be used is being run. But, I can't figure out how to write the mock. mock(controller) isn't correct, nor does mocking ApplicationController or Ability seem to work.
How do I write this kind of mock?
I believe it would be better to test authorization in another spec like ability_spec.rb in order for you to separate their responsibilities. By doing so you won't have to test the same authorization method that you use on different controllers.
heres some other details
It turns out the way I was writing above works.. must have had a typo earlier.
So, to check that an authorize! check is invoked in the controller, you just need to write:
it "should check the user can do_this_action" do
mock(controller).authorize!(:some_action, some_object)
get :some_action
end
I've got some funny behavior when trying to get Devise to sign in properly in my controller testing. It seems to work in certain cases, but not in others. I'm not sure if this is an interaction between Devise and FactoryGirl or something else at work.
First off, here's my factories:
factory :advisor do
name "Jason Jones"
association :user
initialize_with {Advisor.find_or_create_by_name('Jason Jones')}
end
factory :client do
name "Rich Homeowner"
association :advisor
end
factory :user do
email "jason#jones.com"
password "testpassword"
initialize_with {User.find_or_create_by_email('jason#jones.com')}
end
my controller:
class ClientsController < ApplicationController
before_filter :authenticate_user!
def destroy
#client = current_user.advisor.clients.where(:id => params[:id]).first
#client.destroy
flash[:notice] = 'Client deleted.'
redirect_to clients_path
end
and my controller test:
describe "DELETE destroy" do
it "should delete a client" do
a = FactoryGirl.create(:advisor)
c = FactoryGirl.create(:client, :advisor => a)
login_user(a.user)
expect{
delete :destroy, :id => c.id
response.should be_redirect
assigns(:client).should eq(c)
}.to change(Client, :count).by(-1)
end
end
the login_user spec helper is where it gets funky. if I uncomment the line below, forcing the user to be set to the FactoryGirl object, the test passes. If I leave it commented, Devise attempts to sign in as the passed user (which I have verified via debugging is the same user in the DB), but it does not actually sign in. The sign_in call actually returns the same array in both cases, but based on following the execution path, the controller code is never executed, because Devise redirects to the login page.
def login_user(user=nil)
#request.env["devise.mapping"] = Devise.mappings[:user]
if user.nil?
user = FactoryGirl.create(:user)
end
# user = FactoryGirl.create(:user) # uncommenting this line causes test to pass
sign_in user
end
How do I get the sign_in to work properly?
For the record, when it comes to TDD for Rails, I spend 10 min getting my actual code to work properly and 2 hours jumping through hoops to get my test code to do what it's supposed to.
I recently started trying to swallow the philosophy of TDD and admit that I had the same exact feeling as you did at first. Your time estimates seem pretty accurate, 10 minutes of development and 2 hours of test case implementation. My first advice is, like many things in life, it gets better. The first time you make a seemingly innocuous change then realize that you've broken half your test regression you'll be glad you took the pill.
With that said, this is going to sound like a cop out because you're asking why Devise doesn't work and my answer is: you shouldn't care. Clearly you're doing something wrong, and I'm afraid I can't tell what it is from the information given, but I think I can help anyway.
The only thing I see wrong above is that your spec is testing at least four things:
Response is a redirect.
#client is assigned.
A Client is destroyed.
Devise is providing proper authentication.
A spec should test one thing and one thing only. As tempting as it may be to test more, I don't recommend it. Cucumber or other integration tests test bunches of things, but not specs.
Devise is not something you should test here, so stub it out. I think something like this will work:
before :each do
#advisor = FactoryGirl.create(:advisor)
controller.stub(:authenticate_user!).and_return(true)
controller.stub(:current_user).and_return(#advisor.user)
end
After this, create three different it "should" do blocks for the three things you're testing.
Another tip is I don't think you need to specify association when defining a FactoryGirl factory. I think this is only needed for polymorphic associations. Normally you can just give the name of the association without a value and it will run the factory with the same name. Just watch out for infinite loops.
I hope that helps.
I am having a terrible time understanding the assignment function that is needed, as explained in chapter 8.2.3. of the Hartl's tutorial.
As context, he is focused on the second line of the following sign_in function:
def sign_in(user)
cookies.permanent[:remember_token] = user.remember_token
self.current_user = user #<-- this line
end
Where he mentions because its an assignment, it must be then separately defined as
def current_user=(user)
#current_user = user
end
Where the method current_user= expressly designed to handle assignment to current_user. My confusions is:
Why is this even necessary? I thought that a simple = would allow you to assign things. For example user.email = hello#kitty.com
Also, when eventually he will code redirect_to current_user, how does something that belongs to the SessionsController get translated to a view controlled by UsersController?
Thanks!!
The reason being it is needed as to avoid confusion (for the interpreter/VM) between method invocation and variable assignment
def foo
# Two completely different things!
bar = "baz" # assigns baz to local variable bar
self.bar = "baz" # invokes the bar= method with parameter of baz
end
What's happening there is that he is doing two things, firstly invoking the current_user= method with the user object and secondly, setting that to #current_user (it's not a great example - you'd probably end up doing a lot more in real life if you were to make a current_user= method such as setting up session variables).
secondly redirect_to current_user is equivalent to redirect_to user_path(current_user) - check out http://api.rubyonrails.org/classes/ActionController/Redirecting.html for more details which explains the different parameter kinds that redirect_to can take. Note this is a redirect, not a render - so a second HTTP request happens here.
I am needing to stub the response of a current_user method in an Rspec/capybara request spec. The method is defined in ApplicationController and is using helper_method. The method should simply return a user id. Within the test, I'd like this method to return the same user id each time.
Alternatively, I could fix my problem by setting session[:user_id] in the spec (which is what current_user returns)... but that doesn't seem to work either.
Are either of these possible?
Edit:
Here is what I've got (it is not working. It just runs the normal current_user method).
require 'spec_helper'
describe "Login" do
before(:each) do
ApplicationController.stub(:current_user).and_return(User.first)
end
it "logs in" do
visit '/'
page.should have_content("Hey there user!")
end
end
Also not working:
require 'spec_helper'
describe "Login" do
before(:each) do
#mock_controller = mock("ApplicationController")
#mock_controller.stub(:current_user).and_return(User.first)
end
it "logs in" do
visit '/'
page.should have_content("Hey there user!")
end
end
skalee seems to have provided the correct answer in the comment.
If the method you're trying to stub is an instance method (most likely) and not a class method then you need use:
ApplicationController.any_instance.stub(:current_user)
Here are a couple of examples of the basic form.
controller.stub(:action_name).and_raise([some error])
controller.stub(:action_name).and_return([some value])
In your particular case, I believe the proper form would be:
controller.stub(:current_user).and_return([your user object/id])
Here's a full working example from a project I work on:
describe PortalsController do
it "if an ActionController::InvalidAuthenticityToken is raised the user should be redirected to login" do
controller.stub(:index).and_raise(ActionController::InvalidAuthenticityToken)
get :index
flash[:notice].should eql("Your session has expired.")
response.should redirect_to(portals_path)
end
end
To explain my full example, basically what this does is verify that, when an ActionController::InvalidAuthenticityToken error is raised anywhere in the app, that a flash message appears, and the user is redirected to the portals_controller#index action. You can use these forms to stub out and return specific values, test an instance of a given error being raised, etc. There are several .stub(:action_name).and_[do_something_interesting]() methods available to you.
Update (after you added your code): per my comment, change your code so it reads:
require 'spec_helper'
describe "Login" do
before(:each) do
#mock_controller = mock("ApplicationController")
#mock_controller.stub(:current_user).and_return(User.first)
end
it "logs in" do
visit '/'
page.should have_content("Hey there user!")
end
end
This works for me and gives me a #current_user variable to use in tests.
I have a helper that looks like this:
def bypass_authentication
current_user = FactoryGirl.create(:user)
ApplicationController.send(:alias_method, :old_current_user, :current_user)
ApplicationController.send(:define_method, :current_user) do
current_user
end
#current_user = current_user
end
def restore_authentication
ApplicationController.send(:alias_method, :current_user, :old_current_user)
end
And then in my request specs, I call:
before(:each){bypass_authentication}
after(:each){restore_authentication}
For anyone else who happens to need to stub an application controller method that sets an ivar (and was stymied by endless wanking about why you shouldn't do that) here's a way that works, with the flavour of Rspec circa October 2013.
before(:each) do
campaign = Campaign.create!
ApplicationController.any_instance.stub(:load_campaign_singleton)
controller.instance_eval{#campaign = campaign}
#campaign = campaign
end
it stubs the method to do nothing, and sets the ivar on rspec's controller instance, and makes it available to the test as #campaign.
For Rspec 3+ the new api is:
For a controller test, nice and short:
allow(controller).to receive(:current_user).and_return(#user)
Or for all instances of ApplicationController:
allow_any_instance_of(ApplicationController).to receive(:current_user).and_return(#user)
None of the provided responses worked for me. As in #matt-fordam's original post, I have a request spec, not a controller spec. The test just renders the view without launching a controller.
I resolved this by stubbing the method on the view as described in this other SO post
view.stub(:current_user).and_return(etc)
I'm retroactively writing some tests, using RSpec, for a Rails project.
I'm using the CanCan gem to provide authorization. I decided to write a spec that will test the ability.rb model.
I then went on to test my remaining models.
I've moved on to controllers, and I've run into a huge snag: I'm testing my abilities all over again!
Basically, I have to stub out a series of models, and stub out their associations; otherwise the response just returns 403 Forbidden.
The reason for this, is that the controller is basically in charge of worrying about authorization.
I'm not quite sure where to go from here. I'm stubbing out up to 6 models, just to write a single test.
I know the abilities work, that's what ability_spec.rb is for.
So this question is really 2-fold:
Should I be testing the ability model separately?
Should the controller tests be concerned with proper permissions?
Edit
require 'spec_helper'
include Devise::TestHelpers # to give your spec access to helpers
describe TokensController do
before(:each) do
#mock_user = User.new(:username => "bob", :email => "user#user.com", :password => "longpassword")
#mock_user.role = "admin"
sign_in #mock_user
#Ability.stub!('can').and_return(true)
end
it "should let me see grids/:g_id/tokens index" do
test_grid = mock_model(Grid)
test_token = mock_model(Token)
Grid.stub!(:find).and_return(test_grid)
Token.stub!(:find).and_return(test_token)
get 'index'
a1 = Ability.new(#mock_user)
a1.can?(:index, Token).should be_true # This line works fine; as it should
puts response.status #This returns 403, which means CanCan::AccessDenied was raised
end
end
Thanks,
Robbie
Not sure if this is too late for you, but I just ran into the same issue, and solved it using the following code sample --
before do
#user = Factory.create(:user)
sign_in #user
#abilities = Ability.new(#user)
Ability.stub(:new).and_return(#abilities)
end
end
I've stubbed out Ability#new, giving me a reference to the instance of Ability that controls the current user. Then, I can stub out specific abilities like this:
#abilities.stub!(:can?).with(:destroy, regatta).and_return(true)
or give admin privileges:
#abilities.stub!(:can?).and_return(false)
I do test the cancan model separately, but testing what it will allow in what conditions.
I think if you are doing things like
authorize! :take_over, #the_world
Then I do think you should be testing that in the controller. I'm not sure you need to test ALL 6 versions of your models though.
You can stub out the Ability.can? class and have it respond true/false, and test how your controller handles when it can (and more importantly) when it cannot continue.
Similar to Sam's answer, but from the CanCan wiki page on testing:
Controller Testing
If you want to test authorization functionality at the controller level one option is to log-in the user who has the appropriate permissions.
user = User.create!(:admin => true) # I recommend a factory for this
# log in user however you like, alternatively stub `current_user` method
session[:user_id] = user.id
get :index
assert_template :index # render the template since he should have access
Alternatively, if you want to test the controller behavior independently from what is inside the Ability class, it is easy to stub out the ability with any behavior you want.
def setup
#ability = Object.new
#ability.extend(CanCan::Ability)
#controller.stubs(:current_ability).returns(#ability)
end
test "render index if have read ability on project" do
#ability.can :read, Project
get :index
assert_template :index
end
If you have very complex permissions it can lead to many branching possibilities. If these are all tested in the controller layer then it can lead to slow and bloated tests. Instead I recommend keeping controller authorization tests light and testing the authorization functionality more thoroughly in the Ability model through unit tests as shown at the top.
I think authorization needs to be done mainly for controllers to make sure your authorization is working correctly with your controllers. So to make it DRY you can implement your own matcher to be used like this
let!(:user) {create :user}
before { login_user_request user}
it "grants admin access to show action" do
expect{ get :show, {id: user.id} }.to be_authorized
end
it "denies user access to edit action" do
expect{ get :edit, {id: user.id} }.to be_un_authorized
end
and then implement these matchers with your own way to test how a request will be authorized or not
RSpec::Matchers.define :be_authorized do
match do |block|
block.call
expect(response).to be_success
end
def supports_block_expectations?
true
end
end
RSpec::Matchers.define :be_un_authorized do
match do |block|
expect{
block.call
}.to raise_error(Pundit::NotAuthorizedError)
end
def supports_block_expectations?
true
end
end
Why don't you include a
can :manage, :all do
user.is_ultrasuper == 1
end
in your Ability and then have a is_ultrasuper param in one of your fixture users:
one:
id: 1
username: my_username
is_ultrasuper: 1
Then log this user in at setup of your tests. This in tests you should be able to do anything at all.