Rails test - checking if user is signed in with Devise - ruby-on-rails

I am trying to test that someone is able to login to my site by making a POST request to my SessionsController. I've seen this way recommended in a few places:
it 'must be able to sign in a user' do
user = create(:user)
post :create, format: :js, user: {email: user.email, password: user.password, remember_me: 0}
assert_response :success
#controller.current_user.must_equal user
end
But this test is not correct. Calling #controller.current_user will attempt to authenticate the user using the posted parameters and will return user if the supplied email/password is correct. There is no guarantee that the create action is actually calling sign_in or current_user.
Even if I re-write the test to check that these methods are called, it's possible that other methods could be called e.g. sign_out.
Is there a more definitive way to ultimately check if a user is logged in, and if so, who the user is?
EDIT -
For example, the following test will pass
it 'must sign in a user' do
#controller.current_user.must_equal nil
post :create, format: :js, user: {email: #user.email, password: #user.password, remember_me: 0}
assert_response :success
#controller.current_user.must_equal #user
end
when the SessionsController#create action is:
def create
respond_to do |format|
format.js {
render nothing: true, status: 200
}
end
end

Solution with minimal changes to proposed code in the question:
You need to initialize the system before the test starts. Try prepending following code before your it 'must be able to sign in a user' do code:
before (:each) do
user = FactoryGirl.create(:user)
sign_out user
end
This should turn your test into a valid test for your post controller.
Explanation:
My assumption is, that your test above always succeeds, because the user is already signed in (by other tests run before this one). You could verify this by using byebug in the line after it and run current_user in bybug's console. If it is not nil, the user is already signed in, which is invalidating your test.
Note, that (different from what is discussed above in the comments), current_user does not change the status of the user; it is a read-only function.
Shorter/cleaner solution:
In my opinion, there is a a cleaner way to perform such a test like follows:
def sign_in_via_post(user)
post :create, format: :js, user: {email: user.email, password: user.password, remember_me: 0}
end
...
before (:each) do
user = FactoryGirl.create(:user)
sign_out user
end
it 'must be able to sign in a user' do
{ sign_in_via_post user }.should change { current_user }.from(nil).to(user)
end
With the should change from nil to user statement, you verify, that the user was logged out before the test begins and that the user is logged in, after the test has been performed.
Note, that the part
{ sign_in_via_post user }.should change { current_user }.from(nil).to(user)
is equivalent to the (maybe easier to understand) code
{ sign_in_via_post user }.should change { user_signed_in? }.from(false).to(true)
as discussed here.

Related

Rails devise: How to sign in a different account without sign out previous one

Sign in to a account (A), Close the tab, and go back to the website
Sign in to a different account (B)
Expected result: You are now signed in to account B
Actual result: You are still signed in to account A
This appears to be because the session is not being cleared before running authentication methods.
The Warden authentication method is idempotent - it looks to the session first and if there's an authenticated account there, it doesn't check the incoming credentials.
Therefore when we try to authenticate using this method but an existing account is logged in, it just uses the existing account no matter whether the incoming credentials are valid or not.
So our current solution would be to destroy the session in the new method before calling warden.authenticate!.
Here is my session_controller
def create
session.destroy
warden.authenticate!(scope: :account)
super do |resource|
......
end
...
end
but when I was writing the test case, it always hard to run step by step into the second post. it always failed in the middle of the second post action
it 'changes to other account if you try to sign in without signing out' do
post :create, params
byebug
post :create, new_params
expect(subject.current_account).to eq new_account
end
use the warden test helpers login_as(user) and logout, so the test would be something like
login_as(User.first)
post :create, params
assert page.success
logout
post :create, new_params
assert page.404_access_denied
use a as_user() helper which wraps up those calls
https://github.com/code-and-effect/effective_test_bot/blob/master/test/support/effective_test_bot_login_helper.rb
(these are all minitest examples)
https://github.com/heartcombo/devise/wiki/How-To:-Test-controllers-with-Rails-(and-RSpec)
So here are two examples which can run successfully in my code:
it 'changes to other account if you try to sign in without signing out' do
post '/accounts/sign_in', { account: { email: account.email, password: account.password } }, json_headers
post '/accounts/sign_in', { account: { email: other_account.email, password: other_account.password } },
json_headers
expect(response.status).to eq(201)
expect(response_body).to include('id' => other_account.id)
end
it 'causes the borrower to be redirected to its sign out path' do
login_as account, scope: :account
delete '/accounts/sign_out', { account: { email: account.email, password: account.password } }
expect(response).to redirect_to(account.sign_out_url)
end

How to test updating user's password in RSpec

I am using Rails 5.2, Ruby 2.4.1, and Rspec. I am trying to make an automation test using Rspec to update a User's password. I know the code works from manually testing.
The RSpec test does not pass the #user.update_attributes(user_params) condition in the controller and then goes to the else condition. Thus, my RSpec test says that the passwords are still equal to each other. How can I get my RSpec test to pass the condition?
Here is the method
# Creates user, saves old password, generates a url for user to go to, updates password, reloads user, and test if old password equals new password
context "with a valid token" do
it "updates the user's password and resets the token" do
test_users = User.create(first_name: 'chase', last_name: 'dougherty', email: 'chase#gmail.com', password: '1', password_confirmation: '1')
old_password = test_users.password
test_users.generate_password_reset_token!
patch :update, params: { id: test_users.password_reset_token, user: { password: 'newpassword', password_confirmation: 'newpassword' } }
test_users.reload
expect(test_users.password).to_not eq(old_password)
end
end
Here is the Controller
# Finds user, test if update_attributes is true, updates password, logs user in, redirects user, displays flash
def update
#user = User.find_by(password_reset_token: params[:id])
if #user && #user.update_attributes(user_params)
#user.update_attribute(:password_reset_token, nil)
session[:user_id] = #user.id
redirect_to '/maps'
flash[:notice] = "Password updated"
else
flash[:notice] = "Password reset failure."
render action: 'edit'
end
end
private
def user_params
params.require(:user).permit(:password, :password_confirmation)
end
If you use has_secure_password method in your user model, you can use this syntax for check password has been changed:
it "changes user's password" do
expect { send_request }.to change { user.reload.authenticate(password) }.from(false).to(user)
end
If the update_attributes line is failing, you probably have some validations on the User model that are firing and causing it to return false.
Also, I would advise against "creating" a user object in the test files. Especially because the first time you run the tests it will create the entry, but then every time after that it will return a User instance that is not saved to the database (because of uniqueness violations in the data) and the tests may not run as expected.
Unless you want to clean up your created user objects after the test runs. Otherwise you will want to use factory_bot and stub out most of these models and the database calls.

Rspec prevent method from being called

I am testing a controller method for creating new orders (e-commerce-like app). If user is present in the system, he should be redirected to new_user_session_path, else to new_order_path. Simple as that.
This is my orders_controller.rb
def new
if !User.where(phone: params[:phone]).blank? && !user_signed_in?
redirect_to new_user_session_path()
flash[:info] = "Already present"
else
#order = Order.new
#menu = Menu.find(params[:menu_id])
#menu_price = #menu.calculate_price(#menu, params)
end
end
In my app, I need the calculate_price method to be called, because it calculates the overall price given the params. But in my test, I just want to ensure, that the redirect is correct.
Right now I'm getting errors like (they are sourced inside the Menu.rb file, since calculate_price is called) :
Front::OrdersController#new redirects user to new order page if user is not present in the system
Failure/Error: menu_price_change = menu_amount.split(",")[1].gsub(" ","").gsub("]",'')
NoMethodError:
undefined method `split' for nil:NilClass
This is my spec file:
require 'rails_helper'
describe Front::OrdersController, type: :controller do
describe '#new' do
# Set up dummy menu
let (:menu) { Menu.create() }
it "redirects user to sign up page if user is present in the system" do
user = User.create(name: "Bob", password: "bobspassword", phone: "+7 (903) 227-8874")
get :new, params: { phone: user.phone }
expect(response).to redirect_to(new_user_session_path(phone: user.phone))
end
it "redirects user to new order page if user is not present in the system" do
non_present_phone = "+7 (903) 227-8874"
get :new, params: { phone: non_present_phone, menu_id: menu.id}
expect(response).to redirect_to(new_order_path)
end
end
end
Of course I could provide all the params, but there is a pretty big amount of them and besides, I just want to test the correct redirect. As far as I know, mocks and subs are useful in this case, when you want to explicitly test the methods. But in my case, I want to - somehow - omit them. How can I ensure that behaviour?
So you want just to test redirects and the errors occured when calculate_price method executes bother you. Why don't you just stub that method? Your spec file might be like this:
require 'rails_helper'
describe Front::OrdersController, type: :controller do
describe '#new' do
# Set up dummy menu
let (:menu) { Menu.create() }
# Check this out
before do
allow_any_instance_of(Menu).to receive(:calculate_price)
# or if you need certain value
allow_any_instance_of(Menu).to receive(:calculate_price).and_return(your_value)
end
it "redirects user to sign up page if user is present in the system" do
user = User.create(name: "Bob", password: "bobspassword", phone: "+7 (903) 227-8874")
get :new, params: { phone: user.phone }
expect(response).to redirect_to(new_user_session_path(phone: user.phone))
end
it "redirects user to new order page if user is not present in the system" do
non_present_phone = "+7 (903) 227-8874"
get :new, params: { phone: non_present_phone, menu_id: menu.id}
expect(response).to redirect_to(new_order_path)
end
end
end

RSpec testing devise controller actions, DELETE failing

I'm using RSpec to test my implementation of the mixture of Devise and the simple_token_authentication gem.
I using devise_for to tell Devise where to look for my sessions controller (source).
devise_for :users, controllers: {
registrations: 'users/devise/registrations',
sessions: 'users/devise/sessions'
}
In my sessions controller, I invoke a custom method if the request has a specific header (source).
def create
req_from_coposition_app? ? respond_with_auth_token : super
end
def destroy
req_from_coposition_app? ? destroy_auth_token : super
end
I have a test that ensures the user can get an auth token.
The request works as expected (source).
it "should be able to sign in" do
request.headers["X-Secret-App-Key"] = "this-is-a-mobile-app"
request.env['devise.mapping'] = Devise.mappings[:user]
post :create,
user: {
email: user.email,
password: user.password
},
format: :json
expect(res_hash[:email]).to eq user.email
expect(res_hash[:authentication_token]).to eq user.authentication_token
end
Next, I'd like to test signing out (destroying the auth key).
I am trying to use the following code:
it "should be able to sign out" do
token_before = user.authentication_token
request.env['devise.mapping'] = Devise.mappings[:user]
request.headers["X-Secret-App-Key"] = "this-is-a-mobile-app"
request.headers["X-User-Token"] = token_before
delete :destroy, nil, format: :json
expect(user.reload.authentication_token).to_not eq token_before
end
However, the Users::Devise::SessionsController#destroy is never hit.
response.status is 302, and
response.body
#=> "<html><body>You are being redirected.</body></html>"
I have checked rake routes, formatted the request in different ways, and checked that the delete method wasn't being messed with anywhere. I am completely at loss as to why post :create works, but delete :destroy doesn't hit the action.
You're not fooling the before filter on line 4 here https://github.com/plataformatec/devise/blob/master/app/controllers/devise/sessions_controller.rb
Devise thinks no one is signed in and is bouncing you away from the destroy action. Skip it, stub it, trick it.

Controller test fails for rails user authentication

--preface: ignore if you want.
I'm new to rails, and working on a project that will require user authentication.
I found this tutorial and have been trying to go through it and understand what's happening. Of course, it's not exactly what I need as-is, so I've been modifying as I go along. The tutorial is also out of date in some areas, so of course I've had to update my code. So part of my problem is that I'm not sure if the bug is in my modifications, or some function that's been deprecated, or what.
--the question
This is the (simplest) test that fails. (" expected to not be nil" on the first assert statement.)
def test_authentication
#check we can log in
post :login, :user => { :username => "bob", :password => "test" }
assert_not_nil session[:user_id]
assert_equal users(:bob).id, session[:user_id]
assert_response :redirect
assert_redirected_to :action => 'welcome'
end
It calls the user_controller action login:
def login
if request.post?
if session[:user_id] = User.authenticate(params[:user][:username], params[:user][:password])
flash[:message] = "Login succeeded!"
redirect_to_stored
else
flash[:warning] = "Login failed."
end
end
end
which calls the User method authenticate. I know that authenticate works properly, however, because I have a single test that does pass:
def test_registration
#check that we can register and are logged in automatically
post :register, :user => { :username => "newuser", :password => "pass", :password_confirmation => "pass", :email => "newuser#web.com" }
assert_response :redirect
assert_not_nil session[:user_id]
assert_redirected_to :action => 'welcome'
end
which calls the user_controller action register
def register
#user = User.new(params[:user])
if request.post?
if #user.save
session[:user_id] = User.authenticate(#user.username, #user.password)
flash[:message] = "Registration succeeded"
redirect_to :action => 'welcome'
end
else
flash[:warning] = "Registration failed"
end
end
which successfully calls authenticate.
the users fixture has one relevant record:
bob:
username: bob
email: bob#mcbob.com
hashed_password: 77a0d943cdbace52716a9ef9fae12e45e2788d39 # test
salt: 1000
I've tested the hashed password and salt - "test" is the correct password.
So by my analysis, the bug has got to be in one of 3 places:
how I'm sending my post request,
how I'm accessing the parameters in the login action,
or some aspect of the fixture loading.
(originally I was using the tutorial's code to load the fixture explicitly (self.use_instantiated_fixtures = true; fixtures :users), but I read that all fixtures are automatically loaded before testing, so I took it out. That didn't change a thing.)
Of course, since I can't seem to find the problem in those areas, it could just as well be anywhere else.
Is it possible that there's a filter that is preventing your action getting called? If there's a general :before_filter => 'login_required' then you might not be reaching your login functionality at all. (Though admittedly the register action would have to be excluded for that test to pass)
In cases like this it's useful to stick some logging in (or run through a debugger) to see whether you even get to the part of the method that you think is failing. If it were me I'd stick a logger.debug("...") as the first line of the login method and then another after the check for request.post? and then another after the authentication check.

Resources