[rspec-users] assigns and should eql don't work as expected

David Chelimsky dchelimsky at gmail.com
Sat Jul 17 17:53:47 EDT 2010


On Jul 17, 2010, at 2:25 PM, Daniel Salmeron Amselem wrote:
> On Jul 17, 9:41 am, David Chelimsky <dchelim... at gmail.com> wrote:
>> On Jul 17, 2010, at 8:09 AM, David Chelimsky wrote:
>>> On Jul 17, 2010, at 3:29 AM, Daniel Salmeron Amselem wrote:
>> 
>>>> Today I've been writing some tests for a new rails 3 app, but after
>>>> reading the doc fromhttp://rdoc.info/projects/rspec/rspec-expectations,
>>>> I still can't understand why the test doesn't work. My setup is:
>> 
>>>> rvm 0.1.41
>>>> ruby 1.9.2dev (2010-07-11 revision 28618) [x86_64-darwin10.4.0] ->
>>>> ruby 1.9.2-rc2
>>>> rspec 2.0.0.beta.17
>>>> rspec-rails 2.0.0.beta.17
>>>> devise 1.1.rc2
>> 
>>>> This is the test for the controller:
>> 
>>>> require 'spec_helper'
>> 
>>>> describe PeopleController do
>> 
>>>> describe "routes" do
>>>>   it "should route to GET people#new" do
>>>>     {:get => "/people/new"}.should route_to(:controller =>
>>>> "people", :action => "new")
>>>>   end
>>>> end
>> 
>>>> describe "Methods" do
>> 
>>>>   before :each do
>>>>     @member = Factory(:member)
>>>>     sign_in @member
>>>>     @person = @member.build_person
>>>>   end
>> 
>>>>   it "should render form for a new person on GET people#new" do
>>>>     @member.should_receive(:build_person).and_return(@person)
>> 
>>>>     get :new
>> 
>>>>     assigns[:person].should eql(@person)
>>>>     response.should be_success
>>>>     response.should render_template("new")
>>>>   end
>>>> end
>> 
>>>> end
>> 
>>>> And the controller:
>> 
>>>> class PeopleController < ApplicationController
>>>> before_filter :authenticate_member!
>> 
>>>> def new
>>>>   @person = current_member.build_person
>>>> end
>> 
>>>> end
>> 
>>>> When running the test I get:
>> 
>>>> .F.................
>> 
>>>> 1) PeopleController Methods should render form for a new person on GET
>>>> people#new
>>>>   Failure/Error: assigns[:person].should eql(@person)
>> 
>>>>   expected #<Person id: nil, first_name: nil, last_name: nil,
>>>> gender: nil, university: nil, year: nil, email: nil, phone: nil,
>>>> house: nil, user_account_id: 126, user_account_type: "Member",
>>>> home_town: nil, bio: nil, current_location: nil, high_school: nil,
>>>> undergrad: nil, profession: nil, concentration: nil, created_at: nil,
>>>> updated_at: nil>
>>>>        got #<Person id: nil, first_name: nil, last_name: nil,
>>>> gender: nil, university: nil, year: nil, email: nil, phone: nil,
>>>> house: nil, user_account_id: 126, user_account_type: "Member",
>>>> home_town: nil, bio: nil, current_location: nil, high_school: nil,
>>>> undergrad: nil, profession: nil, concentration: nil, created_at: nil,
>>>> updated_at: nil>
>> 
>>> Here's how ActiveRecord defines == (to which it delegates from eql?)
>> 
>>> http://github.com/rails/rails/blob/c6e20586372743ce200449bf0ac21aed04...
>> 
>>> It returns false if the record has no id (!comparison_object.new_record?), even if all of the other attributes match. In order to get this to pass you have to actually save the object so it has an id, not just build it.
>> 
>>> I discussed this with Rails core members a year or two ago and while they agreed this would make testing easier, there were two motivating arguments not to change it: a) conceptually, id-less records are not necessarily the same entity (this one is a bit fuzzy to me) and b) it's a risky change given the amount of rails code in existence.
>> 
>>> The other thing you can do is skip the stubbing and just say:
>> 
>>>  assigns(:person).should be_a_new(Person)
>> 
>>> You could also write a custom matcher - something like match_new_record(other) that compares all of the attributes. Maybe it's have_same_attributes_as:
>> 
>>>  assigns(:person).should have_same_attributes_as(@person)
>> 
>>> I'd consider adding that to rspec-rails. Might be good to have a matcher with docs that explain all this to help avoid this sort of confusion in the future.
>> 
>> Another option would be to add something like this:
>> 
>> RSpec.configure do |c|
>>   c.treat_new_active_record_objects_as_equal
>> end
>> 
>> ... and have that override ==(other) on ActiveRecord::Base. It's invasive, but you have to take an action to do the override.
>> 
>> WDYT?

> Thanks David, this was driving me crazy. In my opinion, I think will
> be a great idea to add a new matcher to rspec-rails to do this kind of
> comparison better than overriding == , and have total control of what
> you want to test in each case. Anyways, thanks for helping me on this.

I added an issue for this: http://github.com/rspec/rspec-rails/issues/#issue/131

Please share ideas there about what this matcher might look like.

Cheers,
David

>>> WDYT?,
>>> David
>> 
>>>>   (compared using eql?)
>>>>   # ./spec/controllers/people_controller_spec.rb:24:in `block (3
>>>> levels) in <top (required)>'
>> 
>>>> Finished in 2.29 seconds
>>>> 19 examples, 1 failure
>> 
>>>> The error with the full backtrace here:http://gist.github.com/479362
>> 
>>>> Which doesn't seem to make sense. Any ideas?
>> 
>>>> Thanks.




More information about the rspec-users mailing list