I want to test a existence of a User model attribute.
So I write like this.
describe "Authentications" do
it "sign up with twitter" do
visit new_user_session_path
expect { click_link "Sign up with Twitter"}.to change(User, :count).by(1)
end
describe "new user" do
let(:new_user) { User.last }
it "should have slug" do
#new_user its(:slug) { should eq("foo") }
new_user.slug should exist
end
end
end
First test passes, but second test fails with error like this.
1) Authentications new user should have slug
Failure/Error: new_user.slug should exist
NoMethodError:
"new user" does not respond to either #exist? or #exists?
# ./spec/features/autentication_spec.rb:13:in `block (3 levels) in <top (required)>'
I think I'm calling method wrong way. How should I use it?
After all I want to check not only existence of it but also the value of it. But it fails also.
If you want to validate presence of a value you should use the method present? that Rails provides.
expect(new_user.slug).to be_present should work for what you want.
First of all, the failing expectation you have is equivalent to:
new_user.slug(subject.should(exist))
This is why your failure message refers to "new user", which is the description of our example and thus the implicit value of subject.
Presumably, you intended the should to have been applied to new_user.slug, in which case, you should have written:
new_user.slug.should exist
However, that will only exist if the value of new_user.slug has an exist? method defined on it (per https://www.relishapp.com/rspec/rspec-expectations/v/2-99/docs/built-in-matchers/exist-matcher), which strings do not.
If you want to test whether something is simply truthy, then you can use:
new_user.slug.should be
If you want to exclude false as a value, then you can use:
new_user.slug.should_not be_nil
The rest of this answer deals with a separate matter, which may or may not impact your test depending on whether or not you have a User in your database prior to the overall describe block being invoked.
Assuming you're operating with transactions on, the user created in your initial it block does not exist in the body of your subsequent describe, so User.first is going to return nil, which explains your errors.
If you want to check that your sign in changes the user count by one and use that sign in with a separate test, you can use a let expression as in the following:
describe "Authentications" do
let(:sign_in) do
visit new_user_session_path
click_link "Sign up with Twitter"
end
it "sign up with twitter" do
expect { sign_in }.to change(User, :count).by(1)
end
describe "new user" do
let(:new_user) { User.last }
before { sign_in }
it "should have slug" do
#new_user its(:slug) { should eq("foo") }
new_user.slug should exist
end
end
end
If you want to combine these tests for purposes of understanding the slug failure, you can do so as follows:
describe "Authentications" do
it "sign up with twitter" do
visit new_user_session_path
expect { click_link "Sign up with Twitter" }.to change(User, :count).by(1)
User.last.slug should exist
end
end
Related
I am experiencing strange very test behavior, with logged in state being handled inconsistently.
The spec logs a user in, visits a (nested or un-nested) index page, and checks that the correct content is displayed. Records are fetched asynchronously, though I don't think this should have an impact.
When each spec is run individually, they each pass. When all specs are run together, they fail because the expected content is missing. Using save_and_open_page reveals this is because the login page is being rendered, rather than the expected index page.
Why does rspec think the user is not signed in when all specs are run together, yet each spec passes individually?
The tests look something like this
let(:user) {create :user}
let(:team) {create :team}
let(:country) {create :country}
before :each do
login_as( user, scope: :user )
end
describe 'unnested' do
it 'should have the expected content', :js do
visit users_path
is_expected.to have_content "some content on the page"
end
end
describe 'nested by team' do
it 'should have the expected content', :js do
visit team_users_path(team)
is_expected.to have_content "some content on the page"
end
end
describe 'nested by nationality' do
it 'should have the expected content', :js do
visit country_users_path(country)
is_expected.to have_content "some content on the page"
end
end
The specs all require javascript (I don't know whether that is important here).
Authentication is handled by Devise, and my rails_helper.rb includes
config.append_after(:each) do
DatabaseCleaner.clean
Warden.test_reset!
end
Why does rspec think the user is not signed in when all specs are run together, yet each spec passes individually?
It took a long time to get to the bottom of this. Posting this hear in case it is of help to anyone else encountering the same issue.
After much searching I eventually found this small mention that login_as may not work with Poltergeist when js is enabled on your test scenarios.
I tried the suggested fix to deal with shared DB connections. Unfortunately this resulted in the following errors:
PG::DuplicatePstatement at /session/users/signin
ERROR: prepared statement "a1" already exists
I tried using the Transactional Capybara gem, but this did not seem to work well with Poltergeist.
Eventually I abandonned login_as completely, and instead wrote a short method that visits the login page, fills in email and password, and logs in that way.
This solution appears to be working. It adds a little overhead, so I'm only using it for tests with JS.
If you are using Capybara gem then there is no need to use :js with test cases
What I did if this helps-
scenario "visit with user signed in" do
user = FactoryGirl.create(:user)
login_as(user, :scope => :user)
visit "/"
expect(current_path).to eq('/')
expect(page).to have_title "Some Random Title"
end
The other way you can login user using feature specs like-
feature 'User signs in' do
before :each do
#user = FactoryGirl.create(:user)
end
scenario "Signing in with correct credentials" do
visit "/"
fill_in "Email", with: #user.email
fill_in "Password", with: #user.password
click_button "Log In"
expect(current_path).to eq("/login/useremail/verification")
expect(page).to have_content "Signed in successfully"
end
end
If your pages are ajax then refer to this https://robots.thoughtbot.com/automatically-wait-for-ajax-with-capybara
Let's say I have various RSpec context blocks to group tests with similar data scenarios.
feature "User Profile" do
context "user is active" do
before(:each) { (some setup) }
# Various tests
...
end
context "user is pending" do
before(:each) { (some setup) }
# Various tests
...
end
context "user is deactivated" do
before(:each) { (some setup) }
# Various tests
...
end
end
Now I'm adding a new feature and I'd like to add a simple scenario that verifies behavior when I click a certain link on the user's page
it "clicking help redirects to the user's help page" do
click_on foo_button
expect(response).to have('bar')
end
Ideally I'd love to add this test for all 3 contexts because I want to be sure that it performs correctly under different data scenarios. But the test itself doesn't change from context to context, so it seems repetitive to type it all out 3 times.
What are some alternatives to DRY up this test set? Can I stick the new test in some module or does RSpec have some built in functionality to let me define it once and call it from each context block?
Thanks!
You can use shared_examples ... define them in spec/support/shared_examples.rb
shared_examples "redirect_help" do
it "clicking help redirects to the user's help page" do
click_on foo_button
expect(response).to have('bar')
end
end
Then in each of your contexts just enter...
it_behaves_like "redirect_help"
You can even pass a block to it_behaves_like and then perform that block with the action method, the block being unique to each context.
Your shared_example might look like...
shared_examples "need_sign_in" do
it "redirects to the log in" do
session[:current_user_id] = nil
action
response.should render_template 'sessions/new'
end
end
And in your context you'd call it with the block...
describe "GET index" do
it_behaves_like "need_sign_in" do
let(:action) {get :index}
end
...
I have a project in which I am using RSpec and Capybara to do unit testing. I have fully flushed out model and controller tests which are passing nicely and handle the heavy lifting for pre-database validation.
I am now testing user experience and front end items and want to know how i could verify that a form did NOT submit. If a user mismatches passwords or some other erred data, I have script to set the error and prevent submission.
I know i could search for error text but where there a way to check that the 'submit' never happened and feel confident that no server trip was made.
I want something like:
it "should not sumbit if user name is less than 3 characters" do
visit /edit_account_settings(#user)
fill_in "username", :with => "fo"
click_button "SAVE"
# HOW DO I DO THIS?
expect( ... ).not_to submit_to_server
end
This is not something that you should be testing in an integration test. In integration tests you are taking the point of view of the end user, and therefore you should only be testing what the user can actually see. If the only evidence the user sees that the form has not been submitted is an error message, then that is what you should test for.
In integration tests we most test what the user would see like if an empty field is given then there must be error message according to validations. But still if you want you check as follow
describe "User Registration" do
before do
visit /edit_account_settings(#user)
fill_in "username", :with => "fo"
click_button "SAVE"
end
it "should not sumbit if user name is less than 3 characters" do
page.should have_content "your error message"
end
it "should create the user and redirect to blah_path" do
current_path.should eq blah_path
end
it "should add user in users table" do
expect { user.create }.to change(User, :count).from(0).to(1)
end
end
How do I assert that a user was not created while using Cucumber? In RSpec, I would use the following block, which I can not translate to Cucumber:
...
describe "with invalid information" do
it "should not create a new user" do
expect { click_button submit }.not_to change(User, :count)
end
end
# Cucumber equivalent
When /^he submits invalid information$/ do
click_button "Sign up"
end
Then /^an account should not be created$/ do
# not sure how to translate the expect block
end
In this example, you'll know the email that the user would use, so you could:
Then /^an account should not be created$/ do
User.where(email: "youremail#example.com").first.should be_nil
end
You could also do
Given I have 3 users
When I submit with invalid information
Then I should have 3 users
You can use a lambda to directly translate your RSpec test, rather than rely on a workaround.
Then /^an account should not be created$/ do
save = lambda { click_button :submit }
expect(save).not_to change(User, :count)
end
While going through Ruby On Rails Tutorial by Michael Hartl,in the section where the author writes integration test to validate his Signup page, he has used code spinet bellow. I got what the code does but couldn't get my head around the 'how' part i.e. couldn't understand order of execution.
expect { click_button "Create my account" }.not_to change(User, :count)
Can someone please explain the semantics of the above chain of methods and blocks and how they fit together?
You'd use expect ... change to verify that a particular method call changes -- or does not change -- some other value. In this case:
expect { click_button "Create my account" }.not_to change(User, :count)
will cause rspec to do the following:
Run User.count and note the value returned. (This can be specified as a receiver and a method name, like (User, :count) in your example, or as an arbitrary block of code, like { User.count }.
Run click_button "Create my account" which is a Capybara method that simulates a mouse click on a link.
Run User.count again.
Compare the results of #1 and #3. If they differ, the example fails. If they're the same, it passes.
Other ways to use expect ... change:
expect { thing.destroy }.to change(Thing, :count).from(1).to(0)
expect { thing.tax = 5 }.to change { thing.total_price }.by(5)
expect { thing.save! }.to raise_error
expect { thing.symbolize_name }.to change { thing.name }.from(String).to(Symbol)
Some docs are here.
How it does this is a bit arcane, and it's not at all necessary to understand how it works in order to use it. A call to expect is defining a structure for rspec to execute, using rspec's own custom DSL and system of "matchers." Gary Bernhardt has a rather neat screencast in which he argues that the mystery of rspec actually falls out naturally from a dynamic language like ruby. It's not a good introduction to using rspec, but if you're curious about how it all works, you might find it interesting.
UPDATE
After seeing your comment on another answer, I'll add a bit about the order of operations. The unintuitive trick is that it's the matcher (change in this case) that executes all of the blocks. expect has a lambda, not_to is an alias for should_not whose job is to pass the lambda on to the matcher. The matcher in this case is change which knows to execute its own argument once, then execute the lambda that it was passed (the one from expect), then run its own argument again to see if things changed. It's tricky because the line looks like it should execute left to right, but since most of the pieces are just passing around blocks of code, they can and do shuffle them into whatever order makes the most sense to the matcher.
I'm not an expert on the rspec internals, but that's my understanding of the basic idea.
Here's an excerpt from from Ryan Bates Railscast on Request Specs and Capybara
require 'spec_helper'
describe "Tasks" do
describe "GET /tasks" do
it "displays tasks" do
Task.create!(:name => "paint fence")
visit tasks_path
page.should have_content("paint fence")
end
end
describe "POST /tasks" do
it "creates a task" do
visit tasks_path
fill_in "Name", :with => "mow lawn"
click_button "Add"
page.should have_content("Successfully added task.")
page.should have_content("mow lawn")
end
end
end
And here's an excerpt from the docs on RSPec Expectations
describe Counter, "#increment" do
it "should increment the count" do
expect{Counter.increment}.to change{Counter.count}.from(0).to(1)
end
# deliberate failure
it "should increment the count by 2" do
expect{Counter.increment}.to change{Counter.count}.by(2)
end
end
So basically, the
expect { click_button "Create my account" }.not_to change(User, :count)
is part RSpec:
expect {...}.not_to change(User, :count)
and part Capybara
click_button "Create my account"
(Here's a link to the Capyabara DSL -- you can search for click_button)
It sounds like you're looking for an overall example with them both. This isn't a perfect example, but it could look something like this:
describe "Tasks" do
describe "GET /tasks" do
it "displays tasks" do
expect { click_button "Create my account" }.not_to change(User, :count)
end
end
end