RSpec/Capybara tests

Question

There are three scenarios only for when the sign up validations fail, so is there a better way of representing them rather than having 4 scenarios? I don't want to create a model folder so please don't suggest that.

Is there a better way of representing this RSpec code on Rails using Capybara?

feature 'Login' do
 before do
 FactoryGirl.create(:user)
 end
 scenario "success login", js: true do
 # set_speed(:slow)
 visit root_path
 click_link 'Login'
 fill_in 'email', :with => '[email protected]'
 fill_in 'password', :with => 'password'
 click_button 'Login'
 expect(page).to have_content('Logged in successfully')
 end
 scenario "failed login", js: true do
 # set_speed(:slow)
 visit root_path
 click_link 'Login'
 fill_in 'email', :with => '[email protected]'
 fill_in 'password', :with => 'something failed'
 click_button 'Login'
 expect(page).to have_content('Invalid login/password combination')
 end
end
feature "Sign Up" do
 scenario "success sign up", js:true do
 visit root_path
 click_link 'Login'
 click_link 'Sign Up'
 fill_in 'user[email]', :with=>'[email protected]'
 fill_in 'user[password]', :with=> 'password'
 fill_in 'user[password_confirmation]', :with=> 'password'
 click_button 'Create User'
 expect(page).to have_content('User successfully added.')
 end
 scenario "failed sign up/Wrong email format", js:true do
 visit root_path
 click_link 'Login'
 click_link 'Sign Up' 
 fill_in 'user[email]', :with=>'signup.example.com'
 fill_in 'user[password]', :with=> 'password'
 fill_in 'user[password_confirmation]', :with=> 'password'
 click_button 'Create User'
 expect(page).to have_content('is invalid')
 end
 scenario "failed sign up/Short Email address", js:true do
 visit root_path
 click_link 'Login'
 click_link 'Sign Up'
 fill_in 'user[email]', :with=>'sign'
 fill_in 'user[password]', :with=> 'password'
 fill_in 'user[password_confirmation]', :with=> 'password'
 click_button 'Create User'
 expect(page).to have_content('is too short (minimum is 5 characters)')
 end 
 scenario "failed sign up/Long Email address", js:true do
 visit root_path
 click_link 'Login'
 click_link 'Sign Up'
 fill_in 'user[email]', :with=>'[email protected]'
 fill_in 'user[password]', :with=> 'password'
 fill_in 'user[password_confirmation]', :with=> 'password'
 click_button 'Create User'
 expect(page).to have_content('is too long (maximum is 50 characters)')
 end 
end

Answer 1

Instead of creating 3 long signup features for 3 diff email cases, you could do something like:

describe "email is in wrong format" do
 let(:user) {FactoryGirl.create(:user)}
 before {user.email = something.with.wrongformat}
 it {should_not be_valid}
end
describre "too long email" do
 let(:user) {FactoryGirl.create(:user)}
 before {user.email = ("a"*60)+"@gmail.com"}
 it {should_not be_valid}
end

It'll be same as signup process coz in both you deal with user creation.

And also as for @tokland answer.

I think it could be better not to repeat pattern of:

it "......." do
 expect(page).to ......
end

But just add subject {page} after before block on the top. It allows you to write just like:

describe "....." do
 before {visit root_path}
 it {should have_content('Desired content'}
end

Answer 2

I think some of your expectations might lead to brittle tests. I would modify the expectations a little. For example:

 expect(page).to have_content('Logged in successfully')

What happens if you changed "Logged in successfully" to "Welcome, mate!", or "Merry Christmas, Mohamad"? Your tests will fail even though the code is sound.

Is "Logged in successfully" part of your spec? Or is your spec "The user should be signed in and have a session."

I think that looking for a specific CSS class on the page, as well as other classes, (link classes that should or should not be present if the user is signed in) might be more robust. I would even look for link text, like "Sign in" and "Sign out".

Sure, those can change too, even CSS classes. But they're less likely to change than messages to the user.

• Kingsley Simon: Hi Mohammad, this was a basic test. I am new to rspec and was just testing out. I do understand that the testing scenario is not strong enough and i do know i need to aply more complex testing procedures. Thanks for the mention.

Answer 3

Some comments:

• Rspec expects the concatenation of feature and `scenario to form a human readable text.

• AFAIK, the orthodoox structure for specs is to perform the actions in the before block and only assertions in it blocks.

• Use before blocks to keep your code DRY.

• Personal opinion: in a feature spec, the less app internals you use, the better. So I'd write "/" instead of root_path.

• The user/password info a in the factory, I'd prefer explicit attributes on the creation.

That's how I'd write the Login feature, the same ideas apply for Signup:

feature 'Login' do
 before do
 FactoryGirl.create(:user, :email => "[email protected]", :password => "password")
 visit root_path
 click_link 'Login'
 end
 scenario "with valid user/password", js: true do
 before do
 fill_in 'email', :with => '[email protected]'
 fill_in 'password', :with => 'password'
 click_button 'Login'
 end
 it "shows the logged in message" do
 expect(page).to have_content('Logged in successfully')
 end
 end
 scenario "with wrong user/password", js: true do
 before do
 fill_in 'email', :with => '[email protected]'
 fill_in 'password', :with => 'something failed'
 click_button 'Login'
 end
 it "shows an error message" do
 expect(page).to have_content('Invalid login/password combination')
 end
 end
end

• Flambino: I agree with your use of before. And I think it's a fair point to use "/" instead of root_path, though I wouldn't insist on it. I'd say using route helpers are fair abstraction, esp. if you have good routing specs already. The root path is a bit special, of course, as it's always "/" - no names or words to complicate things. Anyway, if simple, readable path are a feature in your app, it's probably good to hand-write them. But using the helpers is just fine too.
• Kingsley Simon: prefer to define the route with simple readable path. Good mention on the before. Thanks