I'm following the Ruby on Rails Tutorial, and now I need to write tests for the authorization code, e.g. making sure users can only edit their own profile.
There are two actions to test. One is to ensure a user can't access the page of editing other users' profile. This one is easy, a simple "feature" test in capybara.
But I certainly want to test the PUT action too, so that a user can't manually submit a PUT request, bypassing the edit page. From what I read, this should be done as an rspec "request" test.
Now my question is, do I have to maintain them in different dirs? (spec/features vs spec/requests)? It doesn't sound right since these two scenarios are closely related. How are such tests usually done in Rails?
For example,
describe "as wrong user" do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: "wrong#example.com") }
before { sign_in user }
describe "visiting Users#edit page" do
before { visit edit_user_path(wrong_user) }
it { should_not have_selector('title', text: full_title('Edit user')) }
end
describe "submitting a PUT request to the Users#update action" do
before { put user_path(wrong_user) }
specify { response.should redirect_to(root_path) }
end
end
The second test doesn't work in capybara 2.x since "put" is not supported any longer. It has to be a request test. And now I have to write a second "sign_in" method, since the current one uses methods that are only available to feature tests. Smells like a lot of code duplication.
======== my solution ========
After figuring out how to login in a request test, thanks to Paul Fioravanti's answer,
before do
post sessions_path, email: user.email, password: user.password
cookies[:remember_token] = user.remember_token
end
I changed all tests to request tests. So I don't have to split them into different files. Paul's solution would also work though I think this is cleaner.
describe 'authorization' do
describe 'as un-signed-in user' do
let(:user) { FactoryGirl.create(:user) }
describe 'getting user edit page' do
before { get edit_user_path(user) }
specify { response.should redirect_to(signin_path) }
end
describe 'putting to user update page' do
before { put user_path(user) }
specify { response.should redirect_to(signin_path) }
end
end
describe 'as wrong user' do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: 'wrong#example.com') }
before do
post sessions_path, email: user.email, password: user.password
cookies[:remember_token] = user.remember_token
end
describe 'getting user edit page' do
before { get edit_user_path(wrong_user) }
specify { response.should redirect_to(root_path) }
end
describe 'putting to user update page' do
before { put user_path(wrong_user) }
specify { response.should redirect_to(root_path) }
end
end
end
I ended up going through the arduous process of splitting up my request and feature specs after I finished The Rails Tutorial and upgraded my Sample App to Capybara 2.0. Since you say you're still currently doing the tutorial, I would advise you to just keep with the gems that Hartl specifies (Capybara 1.1.2), finish your Sample App, and then go back to the requests/features issue as a refactoring exercise. For your reference though, this is how I ended up writing my "wrong user" authorization specs:
spec/support/utilities.rb
def sign_in_through_ui(user)
fill_in "Email", with: user.email
fill_in "Password", with: user.password
click_button "Sign In"
end
def sign_in_request(user)
post session_path(email: user.email, password: user.password)
cookies[:remember_token] = user.remember_token
end
RSpec::Matchers::define :have_title do |text|
match do |page|
Capybara.string(page.body).has_selector?('title', text: text)
end
end
spec/features/authentication_pages_spec.rb
describe "Authentication on UI" do
subject { page }
# ...
describe "authorization" do
# ...
context "as a wrong user" do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: "wrong#example.com") }
before do
visit root_path
click_link "Sign In"
sign_in_through_ui(user)
end
context "visiting Users#edit" do
let(:page_title) { full_title("Edit User") }
before { visit edit_user_path(wrong_user) }
it { should_not have_title(page_title) }
end
end
end
end
spec/requests/authentication_requests_spec.rb
describe "Authentication Requests" do
subject { response }
# ...
describe "authorization" do
# ...
context "as a wrong user" do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: "wrong#example.com") }
before { sign_in_request(user) }
context "PUT Users#update" do
before { put user_path(wrong_user) }
it { should redirect_to(root_url) }
end
end
end
end
I primarily used the following two links as reference when trying to figure out how to separate my feature specs from my request specs:
rspec-rails and capybara 2.0: what you need to know
rspec-rails Capybara page
Update:
If you don't want the custom RSpec matcher, you can also use the following in the tests above to get the same result on the title element:
its(:source) { should have_selector('title', text: page_title) }
According to Jnicklas (https://github.com/jnicklas/capybara) you should move all Capybare specs you have in spec/requests to spec/features, since spec/features will now be used by Capybara 2.x. So this means that once you moved your Capybara specs to features, you could completely remove these specs from the spec/requests directory.
Personally, I've finished the Ruby on Rails tutorial with no problems at all. I used Capybara 2.x and never used spec/features (just the 'old' spec/requests). For Rspec 2.x support you have to add require >'capybara/rspec'< to your spec_helper.rb file. Without it, your tests could fail.
Edit:
I've just read trough the Rspec docs. If you are using Capybara in your specs these specs have to be moved to spec/features. If there is no Capybara involved the specs can simply stay in your requests directory.
Feature specs
https://www.relishapp.com/rspec/rspec-rails/v/2-12-2/docs/feature-specs/feature-spec!
Request specs
https://www.relishapp.com/rspec/rspec-rails/v/2-12-2/docs/request-specs
More info, from Rubydoc:
http://rubydoc.info/github/jnicklas/capybara/master#Using_Capybara_with_RSpec
Related
When I run this spec
describe "as wrong user" do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: "wrong#example.com") }
before { sign_in user }
describe "submitting a GET request to the Users#edit action" do
before { get edit_user_path(wrong_user) }
specify { expect(response).to redirect_to(root_url) }
end
end
I get this error
Expected response to be a redirect to http://www.example.com/ but was a redirect to http://www.example.com/signin.
But I thought that after calling this
before { sign_in user }
User should be logged in. Why does that happen?
Btw, here is sign_in method
def sign_in(user, options={})
visit signin_path
fill_in "Email", with: user.email
fill_in "Password", with: user.password
check "Remember me"
click_button "Sign in"
end
It looks like you are using both the capybara dsl (visit and so on) and request specs. The latter, being based on rails integration test has its own methods (get, post etc.) of sending requests.
Both of these track state such as cookies across multiple requests but they are completely separate: mixing the two only causes confusion. Capybara however doesn't give you a response object, but should be able to use page.current_url to check that the redirect has happened.
Alternatively leave your example as is, but change your sign_in helper to use the post method to submit the signing data.
Recent versions of rspec try to help you avoid this by not creating by default specs that have both of the DSLs builtin and instead have separate spec types (spec/api and spec/features) for each (see here).
You need to maintain session
session = Capybara::Session.new(:webkit, my_rack_app)
session.fill_in "Email", with: user.email
session.fill_in "Password", with: user.password
end
session.click_button 'Sign in'
Read more about Capybara here: http://www.rubydoc.info/github/jnicklas/capybara/master/Capybara/Session
Im following Michael Hartl's Ruby on Rails tutorial.
In his Listing 9.42, he shows a test for links to delete users, on index page.Ž
Test is supposed to make sure that user with admin: true attribute sees delete links on user's index page (user's listing page).
Also, admin (first user) is not supposed to see a link to delete himself.
Test code goes as follows:
describe "delete links" do
it { should_not have_link('delete') }
describe "as an admin user" do
let(:admin) { FactoryGirl.create(:admin) }
before do
sign_in admin
visit users_path
end
it { should have_link('delete', href: user_path(User.first)) }
it "should be able to delete another user" do
expect do
click_link('delete', match: :first)
end.to change(User, :count).by(-1)
end
it { should_not have_link('delete', href: user_path(admin)) }
end
end
What puzzles me about this code is this:
it seems only logical to me that the first it clause in the describe block
which mentions path to User.first (which is admin here, cause admin is first in database)
conflicts with the third it clause in the describe block, which requires
that link to admin's delete doesn't exist.
Am I missing something here?
I didnt even run the thing yet, but it seems to me it has to fail.
Not that it is shown in your question but the first it block has no conflict as the first user was created above this code.
let(:user){FactoryGirl.create(:user)}.
The third it block refers to when the admin is signed it should not have a delete button for itself.
here is the full spec for #index:
subject { page }
describe "index" do
let(:user) { FactoryGirl.create(:user) } #First User Created Here
before do
sign_in user
visit users_path
end
it { should have_title('All users') }
it { should have_content('All users') }
describe "pagination" do
.
.
.
end
describe "delete links" do
it { should_not have_link('delete') }
describe "as an admin user" do
let(:admin) { FactoryGirl.create(:admin) } #Admin Created here
before do
sign_in admin
visit users_path
end
it { should have_link('delete', href: user_path(User.first)) }
it "should be able to delete another user" do
expect do
click_link('delete', match: :first)
end.to change(User, :count).by(-1)
end
it { should_not have_link('delete', href: user_path(admin)) }
end
end
end
certainly you should run it to figure out what the actual case. As per my understanding, this depends on how your database cleaner works, if it clean database on every run test which is common case then the above specs will pass.
I was watching Michael Hartl's Rails tutorial, In chapter 9.2.2, Hartl says that we can't use capybara to issue put/patch requests directly to a model,
This was the test code:
describe "for wrong users" do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: "wrong#example.com") }
before { valid_signin user}
describe "when submitting a PATCH request to users#update" do
before { patch user_path(wrong_user) }
specify { expect(response).to redirect_to root_path}
end
end
and valid_signin is like this, intially:
def valid_signin(user, options = {})
visit signin_path
fill_in "Email", with: user.email
fill_in "Password", with: user.password
click_button "Sign in"
end
These tests don't work, as when we issue a put request, we can't use capybara to do this.
So is it like this, that we can't use capybara to test any put/patch requests? And what we should do in general when we need to test put/patch requests and we can't use capybara?
Capybara is for Behaviour Driver Development. Who's behaviour? Human beings.
Can a human being patch? Can he put? He can't. Only computers can.
Can a human being visit, fill_in, click_button? Yes he can. This is what Capybara for.
Bottom line, put computers' actions into unit testing and controller testing, mimic human beings in integration testing by Capybara.
I can't for the life of me figure out why these tests are failing.
When a user puts in their email/password and hits the Log in button, they are redirected to their profile page which puts their first name in the title and displays their first name on the page. It also shows a link to their profile and a sign out link. When I went through the steps in the browser everything was where it should be, but when rspec runs it continues to fail.
What I find really odd is that when I run a user_page_spec test that tests the same elements, those all pass.
I figure it has to do with either the click_button part or the "redirect_to user" in the controller, but any insight would be much appreciated.
Here are the tests-
Passing tests in user_pages_spec.rb-
describe "profile page" do
let(:user) { FactoryGirl.create(:user) }
before { visit user_path(user) }
it { should have_selector('h1', text: user.firstName) }
it { should have_selector('title', text: user.firstName) }
end
Failing tests in authentication_pages_spec.rb -
require 'spec_helper'
describe "Authentication" do
describe "sign in" do
.
.
.
describe "with valid information" do
let(:user) { FactoryGirl.create(:user) }
before do
fill_in "Email", with: user.email
fill_in "Password", with: user.password
click_button "Log in"
end
it { should have_selector('title', text:user.firstName) }
it { should have_link('Profile', href: user_path(user)) }
it { should have_link('Sign out', href: signout_path) }
describe "followed by signout" do
before { click_link "Sign out" }
it { should have_link('Home') }
end
end
end
end
Yup. It's always the simplest of oversights that cause the biggest of headaches.
Here is what happened.
Rather than using the following-
describe "page" do
it "should have something" do
page.should have_selector('')
end
end
Rspec lets you define a subject -
subject { page }
Which allows you to simplify the first code block to the following-
subject { page }
describe "page" do
it { should have_selector('') }
end
This allows you to run multiple tests which reference the page without all the extra typing.
I left out the subject { page } at the very top, so none of my it {} blocks knew what to reference. As soon as that was added in, all tests passed with no problems.
Hope this helps someone else out in the future.
I'm up to the Chapter 9 Exercises in Hartl's Rails Tutorial. I've been trying for ages but can't crack question 6:
Signed-in users have no reason to access the new and create actions in the Users controller. Arrange for such users to be redirected to the root URL if they do try to hit those pages.
First, where should I put these tests? At the moment I'm trying in user_pages_spec.rb but I'm unsure if that's right. And then where should I put the logic itself?
Second, is this what my test should look like:
describe "after signing-in" do
before { sign_in(user) }
describe "creating a new user" do
before { put new_user_path }
specify { response.should redirect_to(root_url) }
end
end
At the moment when I do the above, RSpec tells me
Expected response to be a redirect to but was a redirect to http://www.example.com/signin.
But when I test it in my browser, visiting http://localhost:3000/users/new with a signed-in user, there is no redirect at all (which makes more sense to me because I haven't coded one).
I've even downloaded Hartl's code from github but I can't see where / if he has included this functionality.
Edit:
I've got both
describe "creating a new user" do
before { visit new_user_path }
it { should_not have_selector 'title', text: full_title('Sign Up') }
end
And
describe "creating a new user" do
before { get new_user_path } # note the use of GET here not PUT
specify { response.should redirect_to(root_url) }
end
to work properly. Thanks to #Peter de Ridder for help
I'm not really sure why you have a put request when calling new_user_path.
describe "after signing-in" do
let(:user) { FactoryGirl.create(:user) }
before { sign_in user }
describe "creating a new user" do
before { get new_user_path }
specify { response.should redirect_to(root_url) }
end
end
Now the test should work as supposed. You still have to write the code to actually do the redirecting. But hey, that's the whole challenge. Personally I would check if a user is signed in/present. If so, new and create actions should no longer be accessible.