I have a helper which has some logic for controlling the display of a partial :
module BannerHelper
def show_add_friend_link?
!current_page(friends_path) && !current_user.has_friends?
end
end
require 'rails_helper'
describe BannerHelper do
context 'when user has friends'
it 'does not show the add friends link' do
expect(helper.show_add_friend_link?).to eq false
end
end
end
I'm trying to create a test (using rspec 3.2) but current_user isn't defined. I have been able to use current_user from controller tests. current_user is defined in application_controller. Perhaps current_user shouldn't be referred to from a helper though I am not sure where to place this logic.
You have two options.
Since the RSpec group that described an Helper mixes the helper module into itself, you can define the current_user as method inside the example.
describe BannerHelper do
context 'when user has friends'
let(:current_user) { instance_double("User", has_friends: true) }
it 'does not show the add friends link' do
expect(show_add_friend_link?).to eq false
end
end
end
Use dependency injection, and change the helper method to accept the current_user as parameter.
I have solved this by abandoning RSpec's helper test features and instead testing helper modules within the controller test ecosystem. Doing so provides access to the request and session objects, as well as other helper methods.
Here is an example:
describe BannerHelper, type: :controller do
controller(ApplicationController) do
include BannerHelper
end
describe "#show_add_friend_link?" do
context 'when user has friends'
it 'does not show the add friends link' do
allow(subject).to receive(:current_user).and_return(some_user)
# note that instead of ^ mock you can also simply set needed session key as it is accessible.
expect(subject.send(:show_add_friend_link?)).to eq false
end
end
end
end
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 am currently trying to make a dropbox-esque application from a tutorial and I am having trouble trying to figure out how I would test this controller.
this is the AssetsController page
def index
#assets = current_user.assets
end
def show
#assets = current_user.assets.find(params[:id])
Also, assets belong_to :user and user has_many :assets
How would I go about putting that into an rspec test?
Firstly, be very careful about AssetsController.
Assuming you are using Rails 3, the "assets_path" is also the path used to load your application assets, and hence, anything you write to the session in that controller will be ignored silently. Probably not what you want! I'd strongly consider renaming the controller.
I'd first create the user in a sign-in block
module ControllerMacros
def login_user
before(:each) do
#request.env["devise.mapping"] = Devise.mappings[:user]
#user = Factory.create(:user)
sign_in #user
end
end
end
You can then load this in the spec_helper.rb file
RSpec.configure do |config|
config.include Devise::TestHelpers, :type => :controller
config.extend ControllerMacros, :type => :controller
end
Finally, you can use this in the test
describe MyController do
context "#index" do
login_user
before(:each) do
#assets = []
5.times{ #assets << Factory.create(:asset, :user => #user)}
end
it "should test index" do
get :index
assigns(:assets).should eq(#assets)
end
end
end
Now, that should test your asset list correctly.
EDIT: Just realised, I'm using FactoryGirl/Devise here, you may or may not be!
What exactly is you question? How to setup basic tests for the relations or how to test the management of current_user?
The basic tests for this should be in the Model Specs, since it's the job of the model to sort out such things.
I normally test it like this:
1) define the fixtures (or alternately use something like FactoryGirl) for two users and some assets (three for this example). assets for user a are named asset_a_*, those for user b asset_b_*)
2) The test is simply like this:
users(:users_a).assets.should have(3).records
users(:users_a).assets.should include(assets(:asset_a_a))
users(:users_a).assets.should include(assets(:assets_a_b))
users(:users_a).assets.should include(assets(:assets_a_c))
You can finetune this like
users(:users_a).assets.find(assets(:asset_a_a).id).should include(assets(:asset_a_a))
users(:users_a).assets.find(assets(:asset_a_a).id).should_not include(assets(:asset_b_a))
If you absolutely want, you can use similar tests for the controller part.
Though there are quite some discussions if such basic functionality needs testing at all, since it's mostly core Rails functionality to handle the associations you defined in your model.
Personally I do this kind of testing for some reasons. In many cases such permission related associations soon become more complicated and need detailed tests anyway. or somebody may change the parameters of the association and break something.
II - About the current_user part within the controller.
This depends of course on how you handle the authentication to begin with. If you use a plugin like AuthLogic (or whatever) it may have some methods that allow simulating the login in rspec. For authlogic you can do something like this:
before(:each) do
activate_authlogic
UserSession.create(users(:user_a))
end
This will activate authlogic and 'login' user_a.
Then you run you controller
get :index
response.should be_success
response.should render_template :index
assigns(:assets).should # => more or less as above, check that there are the right aessets.
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.
I am trying to test my controller and maintain separation of concerns.
The first concern is "Who is able to execute which action?"
I am using authlogic for authentication and be9's acl9 for authorization. But this should not matter, all my authorization concerns are handled in a before_filter. I am testing such a before_filter by something similar to this:
describe SomeModelsController, "GET to index (authorization)" do
before(:each) do
#siteadmin = mock_model(User)
#siteadmin.stub!(:has_role?).with("siteadmin", nil).and_return(true)
end
it "should grant access to a siteadmin" do
controller.should_receive(:current_user).at_least(:once).and_return(#siteadmin)
get :index
response.should be_success
end
end
This spec is working just fine!
Now, the second concern is "Does the action do what it is supposed to do?"
This does not involve checking authorization. The best/cleanest solution would be skipping that before_filter all together and just do something like:
describe SomeModelsController, "GET to index (functional)" do
it "should find all Models" do
Model.should_receive(:find).with(:all)
end
end
Without having to worry about which user with which role has to logged in first. Right now I solved it like that:
describe SomeModelsController, "GET to index (functional)" do
before(:each) do
#siteadmin = mock_model(User)
#siteadmin.stub!(:has_role?).with("siteadmin", nil).and_return(true)
controller.stub!(:current_user).and_return(#siteadmin)
end
it "should find all Models" do
Model.should_receive(:find).with(:all)
end
end
If I now decided that my siteadmin does not have the right to access the index action anymore, it would not only break one spec - namely the spec that HAS to break in such a case - but also the totally unrelated second spec.
I know this is basically a minor issue, but it would be nice if somebody could come up with an (elegant) solution!
To skip the before filter:
controller.class.skip_before_filter :name_of_method_used_as_before_filter
The one caveat (mentioned the docs) is that this will only work for method-reference filters, not procs.
Alternatively, you could stub current_user.has_role?
describe SomeModelsController, "GET to index (functional)" do
before(:each) do
controller.current_user.stub!(:has_role?).and_return(true)
end
it "should find all Models" do
Model.should_receive(:find).with(:all)
end
end
Old question, but I had to solve this just recently. This will only work for Rails 3.1, for earlier versions you should replace _process_action_callbacks with filter_chain (untested)
You can simply delete a matching Proc from the filter chain like so (Test::Unit example):
class RandomControllerTest < ActionController::TestCase
def setup
#controller.class._process_action_callbacks.each do |f|
#controller.class._process_action_callbacks.delete(f) if f.raw_filter.to_s.match(/**<match for your proc>**/)
end
end
end
How about just not doing a GET request?
Try calling the controller method by itself.
controller.index