Tests that require a logged in user / session cookie

Hi,

I’m fairly new to RSpec with Rails and I’m trying to work out how I can
write request specs for resources that require a logged in user.

I can’t get this one to pass:

describe “GET /admin/account” do

it “should have a 200 status code when logged in” do
post “/login”, { :email => @user.email, :password => @user.password
}
response.should redirect_to("/admin")
response.code.should eq(“302”)
get “/admin/account”
response.code.should eq(“200”)
end

end

The login post part works fine and the session gets created correctly in
the login method, but then the test fails at ‘get “/admin/account”’
because the session suddenly is empty.

I have tried another approach where I set the session manually, to
simulate a logged in user:

describe “GET /admin/account” do

it “should have a 200 status code when logged in” do
session[:user_id] ||= @user.id
get “/admin/account”
response.code.should eq(“200”)
end

end

But again the session arrives empty in my authorisation method when
trying ‘get “/admin/account”’.

My guess is that it fails because the session relies on cookies and in
test mode there obviously is no browser and no cookie.
Are there ways to simulate a logged in user in an app that creates
sessions with cookies?

Thanks for any suggestions

On Wed, Aug 24, 2011 at 6:40 PM, Matthias S.
[email protected]wrote:

it “should have a 200 status code when logged in” do
The login post part works fine and the session gets created correctly in
session[:user_id] ||= @user.id
My guess is that it fails because the session relies on cookies and in test
mode there obviously is no browser and no cookie.
Are there ways to simulate a logged in user in an app that creates sessions
with cookies?

Thanks for any suggestions


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

What you are doing should work. Are there any before_filters altering
the
session? Maybe a gem doing it? Maybe you have an admin namespace that
calls/uses a different session?

On 25/08/2011, at 11:10 AM, Justin Ko wrote:

describe “GET /admin/account” do

get “/admin/account”

Thanks for any suggestions

What you are doing should work. Are there any before_filters altering the
session? Maybe a gem doing it? Maybe you have an admin namespace that calls/uses a
different session?

I have an admin namespace, but does that effect the normal ‘session’
object in any way?

I’ve done some more tests and setting the session in the RSpec code via
session[:user_id] =|| @user.id definitely works, however when the GET
request starts, the session is empty in the application_controller
before anything else is executed. I still can’t figure out where the
session gets lost between RSpec and the app. I reduced the gems to a
minimum set of Rails, Mongoid, BCrypt, Mail, RSpec, Cucumber and
Factory_Girl, but didn’t make a difference.

Forgery protection is disabled for test environment.

On Thu, Aug 25, 2011 at 7:38 AM, Matthias S.
[email protected]wrote:

I’m fairly new to RSpec with Rails and I’m trying to work out how I can
response.code.should eq(“302”)

end
sessions with cookies?
I have an admin namespace, but does that effect the normal ‘session’ object
Forgery protection is disabled for test environment.


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

I assume you’re on the latest version of Rails and RSpec?

Also, I’m going to need to see some code. The spec and the controller
action
(and before_filter).

On 25 August 2011 14:38, Matthias S. [email protected]
wrote:

I’m fairly new to RSpec with Rails and I’m trying to work out how I can
response.code.should eq(“302”)

end
sessions with cookies?
I have an admin namespace, but does that effect the normal ‘session’ object
Forgery protection is disabled for test environment.


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

If you are using Cucumber (which is in your minimal set of Gems), you
don’t
need to write this sort of test. A Cucumber feature will already cover
this.
RSpec has a wealth of testing tools to cover all sorts of different
environments/conditions/styles. This makes it very easy for you to waste
time writing tests you don’t need. For Rails applications with cucumber
and
rspec, you only really need to write model specs and features (if you
keep
your controllers, skinny) *. If a test is difficult to do its always
worth
thinking, Why am I doing this test? Could I do another test thats
easier?

HTH

Andrew

  • I don’t expect everyone to agree with this

On 2011-08-25 11:42 AM, Andrew P. wrote:

    method when trying 'get "/admin/account"'.
What you are doing *should* work. Are there any before_filters
is empty in the application_controller before anything else is
http://rubyforge.org/mailman/listinfo/rspec-users

Could I do another test thats easier?

HTH

Andrew

  • I don’t expect everyone to agree with this

I’m of the same opinion on this issue as you, Andrew. I’ve been trying
for a long time to keep my controllers skinny, and I’ve recently been
thinking that the Cucumber suite should be sufficient for covering them.
Like you, though, I expect there are quite a few who disagree. But, hey,
so goes life…

Peace.

On 25/08/2011, at 11:45 PM, Justin Ko wrote:

response.code.should eq(“302”)

Also, I’m going to need to see some code. The spec and the controller action
(and before_filter).
Yes, I’m running the latest versions of all gems.

I just found this:

It looks a lot like the issue that I have.

The answer mentions that sessions aren’t available in request specs
because of capybara. To be honest I’m not much familiar with what
capybara actually does but I have reproduced this by basically moving
the test into a controller spec, and suddenly the session goes through
and doesn’t show up empty in the authorize method of my app.

On Fri, Aug 26, 2011 at 12:12 AM, Matthias S.
[email protected]wrote:

I can’t get this one to pass:
end

I’ve done some more tests and setting the session in the RSpec code via


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

Oh jeez, I thought you were using a controller spec the entire time
because
of the methods being used. Yes, capybara restricts you from accessing
the
session, which is a good thing for request specs.