I am trying to learn Rspec in a very simple CRUD Rails 3.2.8 app. I'm following the general pattern of Michael Hartl's examples and have been moderately successful with cucumber for the outside in portion. Now I want to test a Twilio SMS feature and cannot seem to get to first base, mostly because I'm not asking the right questions, so I expect to be corrected here and get back on track.
My app has two models, commodity and price and they interact with each other in my cucumber tests, so it appears. I'm aware, like in cucumber, I need an object to start to test its interactions. In my prices controller, I see that I can get the commodity's prices with the below in my prices#create method:
#price = #commodity.prices.build(params[:price])
I ultimately want to generate a factory that will have many prices for a given commodity. But I want to get to base first. Following thoughtbot's examples on their Readme I'm attempting the following in rails console:
FactoryGirl.create(:commodity) do |price|
Commodity.prices.build(attributes_for(:price))
end
The result is: NoMethodError: undefined method `prices' for #
Hmm, I must not be understanding either Rspec or Factory Girl. Here is my basic factories.rb:
FactoryGirl.define do
factory :commodity do
name "corn"
end
sequence :price do |n|
price
date { Time.now }
end
end
Here are my two models:
class Commodity < ActiveRecord::Base
attr_accessible :description, :name
has_many :prices
end
MOST_RECENT = 5
class Price < ActiveRecord::Base
attr_accessible :buyer, :date, :price, :quality, :commodity_id
scope :most_recent, lambda { order("id desc").limit(MOST_RECENT) }
belongs_to :commodity
end
My attempt to understand this is to do it simply in Rails console but the error also appears when I run rspec as well. But why would FactoryGirl, or Rspec, not seem to use the prices method I get with Active Record? Clearly, I'm not understanding something or I would have found the answer on Stack, thanx, sam
In your FactoryGirl.create there are a couple problems. First, the block argument should be commodity, not price. create passes the created object into the block. Second, you're trying to run prices on the Commodity class. In your object relationship, prices is an accessor associated with a specific instance. There is no Commodity#prices method, but any given instance of Commodity will have prices. You can probably use build like that, but I think the canonical way is to use the shift operator to add a Price.
Putting this together gets you:
FactoryGirl.create(:commodity) do |commodity|
commodity.prices << FactoryGirl.create(:price, commodity: commodity)
end
I'm not sure what you're doing with the sequence in your Commodity factory definition. If you're trying to make sure that Commodities are created with Prices by default (without adding them as above), check out some of the tips at http://icelab.com.au/articles/factorygirl-and-has-many-associations/.
Related
I'm relatively new to testing and very new to Rails 4 and rSpec. I am trying to test a controller that uses Devise for authentication and I am stuck. All of the examples I can find are for Rails 3.
I'm using Rails 4.0.3, Devise 3.2.3, rSpec 2.14.1 and FactoryGirl 4.4.0.
class LessonPlansController < ApplicationController
before_action :authenticate_user!
# GET /lesson_plans
def index
#lesson_plans = current_user.lesson_plans.to_a
end
.
.
.
private
# Use callbacks to share common setup or constraints between actions.
def set_lesson_plan
#lesson_plan = LessonPlan.find(params[:id])
end
# Only allow a trusted parameter "white list" through.
def lesson_plan_params
params[:lesson_plan]
end
def lesson_plan_params
params.require(:lesson_plan).permit(:title, :synopsis)
end
end
Here are my factory definitions: (Maybe I don't need to define user_id in the lesson_plan factory?)
FactoryGirl.define do
factory :user do
sequence( :username ) { |n| "user#{n}" }
sequence( :email ) { |n| "foo#{n}#example.com" }
password 'foobarbaz'
password_confirmation 'foobarbaz'
created_at Time.now
updated_at Time.now
end
end
FactoryGirl.define do
factory :lesson_plan do
user_id 1
title "The French Revolution"
synopsis "Background and events leading up to the French Revolution"
end
end
And the test part is where I get stuck.
describe LessonPlansController do
let(:valid_attributes) { { } }
let(:valid_session) { {} }
# describe "GET index" do
it "assigns all lesson_plans as #lesson_plans" do
user=FactoryGirl.create(:user)
sign_in user
lesson_plan = LessonPlan.create! valid_attributes
get :index, {}, valid_session
assigns(:lesson_plans).should eq([lesson_plan])
end
end
I'm not sure what to put in valid_attributes and valid_session (or if I even need them). The test will get as far as signing in the user, but will fail on creation of the lesson_plan. Admittedly this is the default/generated test for rSpec, but I am not sure how to proceed.
Examples I have seen use a before block to set up the user. I haven't been able to find anything on the Devise wiki page covering how to write basic rSpec tests for a controller that requires the user to be logged in. Any pointers would be greatly appreciated!
"I'm not sure what to put in valid_attributes and valid_session (or if I even need them)."
Well that depends what you're testing for.. Say you're testing validations & want to ensure that a record not be created if x column is set to null... then you could try to specifically create a record with invalid attributes (e.g. column: nil) and expect the result to not return true; maybe you want to ensure that it IS created with valid attributes.
You can btw, use `attributes_for(:factory_name)`` since you're using FactoryGirl. And no you don't necessarily need to specify the user's id in your lesson plan factory; unless you always want it to reference user 1. You can simply reference user with no value. Check out http://everydayrails.com/2012/03/12/testing-series-intro.html and especially parts 3-5 for an introduction to testing with RSPec.. I found this a pretty easy to follow guide when I was getting started.
In the latest release of FactoryGirl, some syntactic methods such as Factory.create were depreciated in favor of several others, most notably FactoryGirl.create and the simpler create.
However, experience shows that certain syntaxes are not always appropriate given the context.
Take for example:
FactoryGirl.define do
factory :article do
after_create {|a| a.comments << create(:comment) }
end
factory :comment do
end
end
Where Article has_many Comments, and Comments belongs_to Article. In the above factories, a.comments << create(:comment) issues the error Comment(#nnn) expected, got FactoryGirl::Declaration::Static. Change that line to a.comments << FactoryGirl.create(:comment) and the error goes away.
It is not clear when one syntax should take precedence over any other form.
I learned the abbreviated notation is not supported in callbacks (such as after_create) as of the current version (3.2.0). This information came directly from the FactoryGirl teams via Google groups. I'll update this question when/if it's added in a future version.
As per the FactoryGirl documentation, if you want to omit the FactoryGirl module prefix while calling methods like create and build, you need to mix-in FactoryGirl methods in rspec/test-unit module like this:
# rspec
RSpec.configure do |config|
config.include FactoryGirl::Syntax::Methods
end
Trying to understand the effects of :has_many as its introduced in the Agile Web Development book 4th Edition
The following relationship is set up for the cart
class Cart < ActiveRecord::Base
has_many :line_items, :dependent => :destroy
end
this compliments the associated LineItem class
class LineItem < ActiveRecord::Base
belongs_to :product
belongs_to :cart
end
All is fine, I fully understand the relationship modelling, and just trying to accept that it just 'works'. However, in code the author, instead of using the LineItem.find method to do a search on the underlying table, uses a line_items object, e.g.
current_item = line_items.where(:product_id => product_id).first
Can someone please explain this, and ultimately I imagine, what the effect of the :has_many method call actually is? What is the line_items object, where does it come from? I guess the same question will apply to the effect of the other relational Rails methods.
Thanks.'
Consider my answer just as a very big comment to Chris Kimpton's answer.
First, you should read the API documentation, where the associations are explained pretty nicely.
In short, when you call the method has_many in the code of a class (remember that in Ruby every line is an executed code, so the has_many :something is just a call to some existing method) then that method defines another two methods with the same name as the argument you have passed.
In this case that would be the Symbol :line_items, so the has_many method makes something roughly equivalent to : def line_items(force_reload = false) and def line_items=(objects).
The newly created method line_items returns a collection object of all the LineItem objects filtered by WHERE cart_id = #{self.id} (this is a simplified example).
That collection object works like an Array, but it also responds to some more methods (like find or build) helping you to manage the relation between the Cart object and LineItem.
So, the line:
line_items.where(:product_id => some_id).first
is the equivalent of:
LineItem.where(:cart_id => self.id).where(:product_id => some_id).first
Using the first method (the line_items collection) you do not need to remember about adding that :cart_id => self.id to every statement.
If the code is exactly as you have written here, that line_items object must have been set up somehwere else in that code.
The has_many relationship will add a helper method to give the list of associated elements so it could be doing something like this:
cart = Cart.find(1)
line_items = cart.line_items
cart.line_items will return an array of line_items where line_item.cart_id = cart.id
I presume that sample line of code is in a method of the Cart class?
One of the "features" of ActiveRecord / has_many call is to add this pseudo method to your class.
So the Cart class gains a line_items method to access them.
The line_items.where call is searching within the related line_items - not all LineItems, which is what your call would do. It seems to be looking for a line_item related to a specific product - I wonder where the product_id var comes from - method parameter?
On the other side, the belongs_to call on LineItem adds a "cart" method to access the Cart it is in.
Hope this helps,
Chris
I stumbled over a SystemStackError and found where it is caused in the source code. Though, I did not quite understand why it happens. Maybe you can help me.
Here is the scenario:
There are two models Facility and Location given by their model definitions in the following.
class Location < ActiveRecord::Base
belongs_to :facility
accepts_nested_attributes_for :facility
end
class Facility < ActiveRecord::Base
has_many :locations
accepts_nested_attributes_for :locations
end
Now I create an object of each class in the Rails console: rails c.
location = Location.create(...)
facility = Facility.create(...)
Then I want to associate both with each other.
location.facility = facility
facility.locations << location
I cannot execute the last command when I executed the first before - it raises a SystemStackError: stack level too deep. Though, I can run the association commands separate from each other or sequential but in reverse order. The problem is that I cannot add the location again. Why?
Why do both?
This line:
facility.locations << location
Will already set the location's facility to be the specified facility. Both lines in this case are doing the same thing. What I would recommend doing is to use the association builder, like this:
facility.locations.create!(...)
This way, Rails takes care of setting the facility_id field, rather than you doing a manual assignment after it.
The first thing that I would suspect here is that the has_many association is really has_too_many. In other words, you may have too many locations in the relationship.
In fact, given the code you posted, you seem to have created an infinite loop of associations. You wrote:
accepts_nested_attributes_for :facility
I am assuming that this causes ActiveRecord to open the facility attribute where it finds another location with yet another facility attribute ad infinitem. before you dig too deeply, try this to see if it works:
facility.locations << location
location.facility = facility
However, be wary because this might just push the stack error to some other place in the app. If you Google for that error message you can find several people who have run into infinite recursion problems, generally related to saving a record.
I want to test that a staff member is associated with a company in my rspec controller tests.
I would like to end up with this in my create action of the staff controller:
staff.companies << current_company
Where current_company is collected from a session variable.
How do I write a test for this?
I've got these models
class Company < ActiveRecord::Base
has_many :employees
has_many :staff, :through => :employees
end
class Employee < ActiveRecord::Base
belongs_to :company
belongs_to :staff
end
class Staff < ActiveRecord::Base
has_many :employees
has_many :companies, :through => :employees
end
The following test is my attempt to spec the assocation and it fails when I enter in the association code:
it "should belong to the current_company" do
staff.should_receive(:companies)
post :create
end
If I enter the 'staff.companies << current_company' code in my controller I get this error when running that test:
Failure/Error: post :create
NoMethodError:
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
Staff controller create method:
def create
#staff = Staff.new(params[:staff])
if #staff.save
#staff.companies << current_company
redirect_to staff_index_path, :notice => "Staff created successfully!"
else
#company = #staff.firm || current_company
flash[:alert] = "Staff failed to create"
render "new"
end
end
I would use a different approach, since testing that the model should receive a certain message couples your tests too tightly to the implementation. Do you really care whether companies receives #<< or some other method?
Really, what you want to test is whether the user's company is recorded when they post to the page. It doesn't matter how it was recorded. So I'd do something like this:
it "should add the company to the user's list of companies" do
lambda do
post :create
end.should change(staff.companies, :count).from(0).to(1)
staff.companies.map(&:name).should include("Acme, Inc.")
end
This is testing behavior instead of implementation. The advantage is that your test wont fail when someone changes that << to the equivalent push. It also has the advantage of being clearer about your intention and therefore better documenting the code.
If you're in your controller spec, I would use stub_chain
staff.stub_chain(:company, :<<).once.and_return(true)
which will mock out the company call AND the << call AND expect it to be called once.
(At least, that .once should work with stub_chain...)
You can test it with :
staff.should have(1).company
Or if the staff already has other companies, get the count and test for have(count+1).companies.
The problem with the code is that once you stub out a method - it no longer exists on the model anymore.
You have stubbed out the "companies" method (when you set the expectation on it) and it now, no-longer calls the actual, real companies association on the model but the stub that you have created... which returns nil (because you didn't set a returns value on it).
Then, when you try to put a company into this new, null method using << it says it can't do that.
To get around it you can do what you did which is to set a returns value:
staff.should_receive(:companies).and_return([])
which will then make sure that:
#staff.companies << current_company
will not fail with the horrible nil error (because there's and actual, real array for the company to go into).
But really the best thing to do is as the previous people have suggested and test what you actually really need to test - which is that saving a staff with companies will cause a new company to get saved to the db.