This code is working but I want to check that it's robust/good practice/idiomatic.
Background: I'm following Michael Hartl's rails tutorial and I'm working on 8.5 (exercises for chapter 8), decoupling the tests from the implementation.
In user_pages_spec.rb I didn't like the code
expect { click_button submit }.not_to change(User, :count)
Since change(User, :count) looks like a bit of a hack. So in spec/support/utilities.rb I wrote:
def create_user
change(User, :count)
end
And I replaced the line in user_pages_spec.rb with
expect { click_button submit }.not_to create_user
Was this sensible?
Doing that is pretty much just "wrapping" the syntax, I don't think it really adds much to the code. The code you had earlier wasn't too bad, but perhaps you could also consider doing this:
expect { click_button submit }.to_not change{User.count}
Related
So I'm writing my feature test and it goes something like this, note the [[place_holder]]
feature 'Accounts' do
scenario 'creating an account' do
# visit and fill form
expect {
click_button 'Create Account'
}.to [[place_holder]]
success_message = 'Your account has been successfully created.'
expect(page).to have_content(success_message)
end
end
Now I want to somehow place 2 expecations for this block, these expectations are
change(User, :count).by(1)
change(Account, :count).by(1)
Is there a way I could like chain these two exectations into one, yea I know I could just do a test for each in it's scenario, but that code is too WET, no need for duplications, and the feature specs are slow to begin with, no need to make my test suite slower.
Any suggestions/alternatives are appriceated
From rspec 3.1, you can use compound matcher expressions with block expectations.
expect {
click_button 'Create Account'
}.to change(User, :count).by(1).and change(Account, :count).by(1)
http://rspec.info/blog/2014/09/rspec-3-1-has-been-released/#expectations-block-matchers-can-now-be-used-in-compound-expressions
Since the data will presumably be cleared between each test run, you could just check the absolute value, e.g.
expect(User.count).to eq(1)
expect(Account.count).to eq(1)
I think this is more readable.
I'm getting the error:
The expect syntax does not support operator matchers, so you must pass a matcher to #to.
from my rspec which is this:
expect { click_button submit }.to.change(User, :count).by(1)
How can I rephrase the rspec so it passes?
The issue here is that you are chaining your test.
expect { click_button submit }.to.change(User, :count).by(1)
Should become (note the space between to and change.
expect { click_button submit }.to change(User, :count).by(1)
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
I testing with rspec, Im still learning, I guess I'm on the right way... but when I test my rspec file I got this error:
Failures:
1) UsersController signup with valid information should create a user
Failure/Error: expect { click_button submit }.to change(User, :count).by(1)
count should have been changed by 1, but was changed by 0
# ./spec/controllers/user_controller_spec.rb:31
Finished in 1.16 seconds
2 examples, 1 failures
I know what this mean, but I don't know how to fix it, can anyone help me with this trouble please...Also I put my rspec file
require 'spec_helper'
describe UsersController do
describe "signup" do
before { visit new_user_registration_path }
let(:submit) { "Sign up" }
describe "with invalid information" do
it "should not create a user" do
expect { click_button submit }.not_to change(User, :count)
end
end
describe "with valid information" do
before do
fill_in "Email", :with=> "user#example.com"
fill_in "Password", :with=> "foobar"
#fill_in "password_confirmation", :with=> "foobar"
end
(here is that the error appears...below line)
it "should create a user" do
expect { click_button submit }.to change(User, :count).by(1)
end
end
end
end
thanks for your attention
So, you have a failing spec. The spec itself looks ok. So I would check on
is the implementation in place? You can try out the scenario in your browser. Does it work there? If not, you have a failing test (which is good) and need to add the implementation.
if the implementation works, check the spec again carefully. Is the provided information
fill_in "Email", :with=> "user#example.com"
fill_in "Password", :with=> "foobar"
sufficient to create a user?
if you still haven't found the cause, you could use capybaras save_and_open_page (install launchy gem for that) and peek at the page during your test.
ADDITION:
ok, as I said, this should be an integration test - move it from the spec/controllers to the spec/requests folder (and do change the first line, as you're not describing the UsersController! but that should not lead to the problem).
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