I'm trying to get a simple test up and running with rspec + fabrication. Unfortunately, not too many decent articles on this.
In spec/model/event_spec.rb
require 'spec_helper'
describe Event do
subject { Fabricate(:event) }
describe "#full_name" do
its(:city) { should == "LA" }
end
end
In spec/fabricators/event_fabricator.rb
Fabricator(:event) do
user { Fabricate(:user) }
# The test works if I uncomment this line:
# user_id 1
city "LA"
description "Best event evar"
end
In spec/fabricators/user_fabricator.rb
Fabricator(:user) do
name 'Foobar'
email { Faker::Internet.email }
end
I keep getting:
1) Event#full_name city
Failure/Error: subject { Fabricate(:event) }
ActiveRecord::RecordInvalid:
Validation failed: User can't be blank
PS if anyone knows of any online articles / tutorials worth a read on getting started with rspec and fabrication. Do let me know
One of the features of Fabricator is that it lazily generates associations, meaning that your User won't get generated unless the user accessor is called on the Event model.
It looks like your Event model has a validation which requires a User to be present. If this is the case, you need to declare your fabricator like this:
Fabricator(:event) do
# This forces the association to be created
user!
city "LA"
description "Best event evar"
end
This ensures that the User model is created along with the Event, which will allow your validations to pass.
see: http://fabricationgem.org/#!defining-fabricators
Related
I have three models:
User
Company
Commitment
Commitment is a HABTM join table for Users and Companies (i.e., when a User joins a Company, it creates a new Commitment). It also has a few extra columns/attributes:
admin (does the user have admin privileges for this company?)
confirmed_by_admin (has a company admin confirmed this user's request to join the company?)
confirmed_by_member (has the user himself confirmed an invitation to join the company?)
I've also defined a convenience method to quickly determine if a commitment is fully confirmed:
class Commitment < ApplicationRecord
def confirmed?
confirmed_by_admin? && confirmed_by_member?
end
end
Now I'm writing a request spec, but for some reason, the change matcher only works with one of its two syntaxes:
let :carol { FactoryGirl.create(:user) }
let :company { FactoryGirl.create(:company) }
it 'confirms invitation to join company' do
# Initialize unconfirmed commitment
FactoryGirl.create(:commitment, user: carol,
company: company,
confirmed_by_admin: true)
expect do
patch commitment_path(carol.commitments.first),
params: { commitment: { confirmed_by_member: true } }
# for the following syntaxes, ------------------------------------------------
# this works:
end.to change { carol.commitments.first.confirmed?) }.from(false).to(true)
# and this fails:
end.to change(carol.commitments.first, :confirmed?).from(false).to(true)
# ----------------------------------------------------------------------------
end
It appears that carol.commitments.first isn't being reloaded when RSpec tests for the change — I get the following test output:
Failure/Error:
expect do
patch commitment_path(carol.commitments.first),
params: { commitment: { confirmed_by_member: true } }
end.to change(Commitment.find_by(user: carol, company: company), :confirmed?).from(false).to(true)
expected #confirmed? to have changed from false to true, but did not change
# ./spec/requests/commitments_spec.rb:69:in `block (3 levels) in <top (required)>'
What gives? Clearly I can just stick to the curly-brace / block syntax, but I'd like to understand why one works and not the other.
Upon inspecting docs and trying out myself a new rails project replicating your scenarios, and also failing, I believe that the reason why it was failing is because
the "block" form of .change is ran twice ("before" and "after" the expect block), whatever is inside of that block:
.change{ carol.commitments.first.confirmed? }
while the "method" form of .change is ran once for the first argument: carol.commitments.first, but ran twice for the second argument :confirmed?. However, the problem with this is that the the carol.commitments.first at this point inside the spec file does not share the same memory space as that object that has been actually updated in your commitments_controller#update (most likely that object is named #commitment). Although they are the same Commitment record, they are separate instances, and the attribute-values of the other do not automatically changes when the another one changed.
Consider the following which demonstrates a scenario in which this "method" form works:
it 'sometest' do
commitment = FactoryGirl.create(:commitment, user: carol,
company: company,
confirmed_by_admin: true)
expect do
# this commitment object is exactly the same object passed in the `change` below
commitment.confirmed_by_member = true
end.to change(commitment, :confirmed?).from(false).to(true)
end
Disclaimer: This is unverified, but because it was too complex for me write as a comment (with all the sample test code), I wrote it here as an answer. Should anyone know any better, please do let me know.
I am using let to create a user record using factory girl. However i want to use exactly the same variable across 2 tests in the context as the user_id and email are important to the external API i am sending.
However i had no luck making a single variable for using across the examples. Here is my current code
context "User" do
let(:user) { FactoryGirl.create(:user) }
it "should create user and return 'nil'" do
expect(send_preferences(user, "new")).to eq nil
end
it "should not create user preferences again after sending two consecutive same requests" do
expect(send_preferences(user, "new")).to eq "User preferences already saved. No need to re-save them."
end
it "should update user preferences" do
expect(send_preferences(user, "update")).to eq nil
end
end
any clues?
You can use lets within lets:
context "User" do
let(:email_address) { 'test#test.com' }
let(:user) { FactoryGirl.create(:user, email_address: email_address) }
You will then also have access to the email_address variable within all your tests.
This works because previously the email address was being randomly generated by the factory every time the user was created, as we hadn't set a value for it anywhere. So, we called the code below in each test:
send_preferences(user, "new")
It called the 'user' let which created a new user with a completely random email address (as we hadn't give it a specific email value). Therefore during the backend API call it was sending a different email address every time.
let(:user) { FactoryGirl.create(:user) }
However, when we defined the email address 'let' as 'test#test.com', and passed that into the user factory as in the code I provided, we overrode the randomly generated email address with our own static value, So, every time we call the code again:
send_preferences(user, "new")
It now triggers the user factory create which is also taking our new 'email_address' let, which is always set to a specific value of test#test.com every time it is called.
let(:email_address) { 'test#test.com' }
let(:user) { FactoryGirl.create(:user, email_address: email_address) }
Therefore, when the backend API call is made the email address is always what we set it to.
Also, as it is a let we can use that variable in any of the tests themselves if we wish. For example:
it 'should set the email address' do
expect(user.email_address).to eq(email_address)
end
It's quite hard to explain in a few sentences but let me know if that's still not clear.
Having an instantiated variable shared among multiple tests is an anti-pattern 90% of the time in my opinion.
The problem with doing something like the below is you will be creating objects in your db without doing a cleanup.
before(:all) do
#user = FactoryGirl.create :user
end
Sure, you can do a before(:after) block or use DatabaseCleaner, but I think it is much better practice for tests to be as standalone as possible. In your case, make your setup of a send_preferences event before making an expectation on what happens the second time:
context "User" do
let(:user) { FactoryGirl.create(:user) }
# ...
it "should not create user preferences again after sending two consecutive same requests" do
send_preferences(user, "new") # Setup
expect(send_preferences(user, "new")).to eq "User preferences already saved. No need to re-save them."
end
it "should update user preferences" do
send_preferences(user, "new") # Setup
expect(send_preferences(user, "update")).to eq nil
end
end
Testing Rails model validations with RSpec, without testing AR itself
Lets as setup we have model User:
class User < ActiveRecord::Base
validate :name, presence: true, uniqueness: { case_sensitive: false }, on: :create
validate :password, presence: true, format: { with: /\A[a-zA-z]*\z/ }
end
A see several ways to test this:
it { expect(user).to validate_presence_of(:name).on(:create) }
or
it do
user = User.create(name: '')
expect(user.errors[:name]).to be_present
end
My main question is which of the approaches is better and why? Can suggest me different approach?
Additional questions:
How much should I test? As an example, I can write so many tests for the regex, but it will be hell for maintenance.
How much you think will be full test coverage in this example?
The functionalities of:
Rails being able to validate the presence of an arbitrary value on your model
errors being added to an object for an attribute that is missing when a validation for it is configured
are covered in the tests for Rails itself (specifically, in the ActiveModel tests).
That leaves needing to write the tests for the config that covers the business logic of your app eg validating the presence of the specific name attribute on your specific User class etc. In my opinion, the matchers from the shoulda-matchers gem should have you covered:
RSpec.describe User, type: :model do
subject(:user) { build(:user) } # assuming you're using FactoryGirl
describe 'validations' do
specify 'for name' do
expect(user).to validate_presence_of(:name).on(:create)
# NOTE: saving here is needed to test uniqueness amongst users in
# the database
user.save
expect(user).to validate_uniqueness_of(:name)
end
specify 'for password' do
expect(user).to validate_presence_of(:password)
expect(user).to allow_value('abcd').for(:password)
expect(user).to_not allow_value('1234').for(:password)
end
end
end
I think that unless you have specific custom error messages for your errors that you want to test for (ie you've overridden the default Rails ones), then tests like expect(user.errors[:name]).to be_present can be removed (even if you have custom errors, I still think they're of dubious value since those messages will become locale-dependent if you internationalise your app, so I'd test for the display of some kind of error on the page in a feature spec instead).
I can write so many tests for the regex, but it will be hell for maintenance.
I don't think you can really get around this when testing validations for format, so I'd suggest just write some representative test cases and then add/remove those cases as you discover any issues you may have missed, for example:
# use a `let` or extract out into a test helper method
let(:valid_passwords) do
['abcd', 'ABCD', 'AbCd'] # etc etc
end
describe 'validations' do
specify 'for password' do
valid_passwords.each do |password|
expect(user).to allow_value(password).for(:password)
end
end
end
How much you think will be full test coverage in this example?
I've gotten 100% code coverage from reports like SimpleCov when writing unit specs as described above.
These 2 of them should be used, because:
it { expect(user).to validate_presence_of(:name).on(:create) }
=> You are expecting the validate_presence_of should be run on create, this should be the test case for model
it do
user = User.create(name: '')
expect(user.errors[:name]).to be_present
end
=> You are expecting a side effect when creating user with your input, so this should be the test case for controller
Why you shouldn't remove 1 of them:
Remove the 1st test case: what happens if you do database validation level instead, you expect an active record level validation
Remove the 2nd test case: what happens on controller actually creates a new User, how do you expect the error returning!
I just figured out how to display a country name from a country id number on model User. Here is the basic code I am using in a controller and two views to display the name after finding User by its id:
#country_name = Country.find(#user.country_id).name
I am using Factory Girl to simulate user records where the default for country_id is 1 for the United States. Before I added this logic my Rspec2 tests were clean. Now I get the following error when I run my tests. Every test which has similar logic in the view or controller produces the error.
ActiveRecord::RecordNotFound:
Couldn't find Country with id=1
Here are two of the Rspec2 tests I am doing:
describe "profile page" do
let(:user) { FactoryGirl.create(:user) }
before { visit user_path(user) }
it { should have_selector('span', text: user.first_name+' '+user.last_name) }
it { should have_selector('title', text: user.first_name+' '+user.last_name) }
end
The profile page references #country_name which is set as stated above. The country name displays on the screen as expected.
I'm thinking that I need to add something to the Rspec2 tests somehow. I was not sure where to do this. Since #country_name is an instance variable not related to User I felt that maybe I needed to do something directly in my Rspec2 file.
Any help would be appreciated. I have not found anything like this so far but I will continue looking.
Update 6/8/2012 7:27 pm CDT
Here is my user controller logic. Adding the second line here produced the RSpec2 errors. I changed nothing in the RSpec2 tests. #country_name is referenced in show.html.erb.
def show
#user = User.find(params[:id])
#country_name = Country.find(#user.country_id).name
end
I decided to try this but got the same error:
describe "profile page" do
let(:user) { FactoryGirl.create(:user) }
let(:country) { FactoryGirl.create(:country) }
before { visit user_path(user) }
it { should have_selector('span', text: user.first_name+' '+user.last_name) }
it { should have_selector('title', text: user.first_name+' '+user.last_name) }
end
I added the following to factories.rb separate from the user factory.
factory :country do
id 1
name "CountryName"
iso "CN"
end
Again my application logic for the country name is working wonderfully.
Update 6/11/2012 9:09 am CDT
Here is my factories.db file. country_id has a default value of 1 in User. I tried this with country_id defined as below and without a declaration for country_id. I also had the country factory without the id. I still got the errors as described. I tried this before submitting my question here.
FactoryGirl.define do
factory :user do
sequence(:first_name) { |n| "First Name #{n}" }
sequence(:last_name) { |n| "Last Name #{n}" }
sequence(:username) { |n| "Username#{n}" }
sequence(:email) { |n| "person_#{n}#example.com" }
password "foobar"
password_confirmation "foobar"
sequence(:city) { |n| "City #{n}" }
sequence(:state_province) { |n| "State/Province #{n}" }
active_user "1"
country_id 1
factory :admin do
admin true
active_user "3"
end
factory :blocked do
active_user "1"
end
factory :rejected do
active_user "2"
end
factory :not_visible do
active_user "3"
visible false
end
factory :visible do
active_user "3"
visible true
end
end
factory :country do
id 1
name "CountryName"
iso "CN"
end
end
Update 6/11/2012 5:37 pm CDT
After several hours of continuing to search AND COMPLETELY REBOOTING MY COMPUTER (sigh) I was finally able to get the tests to work. I replaced country with user.association :country in the user factory. I put my original two statements after the describe "profile page" do statement back. With the suggested changes I now have no errors. I guess the association will create corresponding rows in Country.
Thanks so much for all the help. It was a combination of the help received with one modification that solved this one.
On to figuring out how to check for changed values.......
Update 6/12/2012 10:55 am
It looks like with all the correcting of code I am able to use #user.country.name with no errors. I will change my code to use this streamline coding.
Let is more for setting up variables for use in the test, if you're using database cleaner or something similar, these are probably getting destroyed in the database on each test run. You should be setting up your factories in the before block:
Edit: I've just realised this is probably because you're trying to match records by explicitly entering ids. This won't work (ids are automatically set by the database), but Factory Girl should deal with your associations, see what happens when you set up the before block like this:
before(:each) do
country = FactoryGirl.create(:country)
user = FactoryGirl.create(:user, country: country)
visit user_path(user)
end
I would also remove the
id 1
line from your country factory, and the line setting up the country_id to 1 on the user factory.
Edit 2: You need to tell Factory Girl about your associations, don't try to set them up by explicitely setting the id field because that won't work.
Remove
country_id 1
from the user factory
id 1
from the country factory, and add this line to the user factory:
country
(yes, just country on it's own - Factory Girl is clever enough to figure out what's going on from that as long as the factory and association is named the same)
By the way, you could change this:
#country_name = Country.find(#user.country_id).name
to
#country_name = #user.country.name
It won't help here, but it's cleaner.
I'm writing integration tests using Rspec and Capybara. I've noticed that quite often I have to execute the same bits of code when it comes to testing the creation of activerecord options.
For instance:
it "should create a new instance" do
# I create an instance here
end
it "should do something based on a new instance" do
# I create an instance here
# I click into the record and add a sub record, or something else
end
The problem seems to be that ActiveRecord objects aren't persisted across tests, however Capybara by default maintains the same session in a spec (weirdness).
I could mock these records, but since this is an integration test and some of these records are pretty complicated (they have image attachments and whatnot) it's much simpler to use Capybara and fill out the user-facing forms.
I've tried defining a function that creates a new record, but that doesn't feel right for some reason. What's the best practice for this?
There are a couple different ways to go here. First of all, in both cases, you can group your example blocks under either a describe or context block, like this:
describe "your instance" do
it "..." do
# do stuff here
end
it "..." do
# do other stuff here
end
end
Then, within the describe or context block, you can set up state that can be used in all the examples, like this:
describe "your instance" do
# run before each example block under the describe block
before(:each) do
# I create an instance here
end
it "creates a new instance" do
# do stuff here
end
it "do something based on a new instance" do
# do other stuff here
end
end
As an alternative to the before(:each) block, you can also use let helper, which I find a little more readable. You can see more about it here.
The very best practice for your requirements is to use Factory Girl for creating records from a blueprint which define common attributes and database_cleaner to clean database across different tests/specs.
And never keep state (such as created records) across different specs, it will lead to dependent specs. You could spot this kind of dependencies using the --order rand option of rspec. If your specs fails randomly you have this kind of issue.
Given the title (...reusing code in Rspec) I suggest the reading of RSpec custom matchers in the "Ruby on Rails Tutorial".
Michael Hartl suggests two solutions to duplication in specs:
Define helper methods for common operations (e.g. log in a user)
Define custom matchers
Use these stuff help decoupling the tests from the implementation.
In addition to these I suggest (as Fabio said) to use FactoryGirl.
You could check my sample rails project. You could find there: https://github.com/lucassus/locomotive
how to use factory_girl
some examples of custom matchers and macros (in spec/support)
how to use shared_examples
and finally how to use very nice shoulda-macros
I would use a combination of factory_girl and Rspec's let method:
describe User do
let(:user) { create :user } # 'create' is a factory_girl method, that will save a new user in the test database
it "should be able to run" do
user.run.should be_true
end
it "should not be able to walk" do
user.walk.should be_false
end
end
# spec/factories/users.rb
FactoryGirl.define do
factory :user do
email { Faker::Internet.email }
username { Faker::Internet.user_name }
end
end
This allows you to do great stuff like this:
describe User do
let(:user) { create :user, attributes }
let(:attributes) { Hash.new }
it "should be able to run" do
user.run.should be_true
end
it "should not be able to walk" do
user.walk.should be_false
end
context "when user is admin" do
let(:attributes) { { admin: true } }
it "should be able to walk" do
user.walk.should be_true
end
end
end