Assigns and should eql don't work as expected

Today I’ve been writing some tests for a new rails 3 app, but after
reading the doc from http://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>

    (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.

On Jul 17, 2010, at 3:29 AM, Daniel Salmeron A. wrote:

“people”, :action => “new”)

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/c6e20586372743ce200449bf0ac21aed04c6b81e/activerecord/lib/active_record/base.rb#L1536

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.

WDYT?,
David

On Jul 17, 2010, at 8:09 AM, David C. wrote:

rspec 2.0.0.beta.17
describe “routes” do
sign_in @member
response.should render_template(“new”)
def new

  1. PeopleController Methods should render form for a new person on GET
    gender: nil, university: nil, year: nil, email: nil, phone: nil,

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.

On Jul 17, 2010, at 2:25 PM, Daniel Salmeron A. wrote:

ruby 1.9.2-rc2
describe “routes” do
sign_in @member
response.should render_template(“new”)
def new
people#new
house: nil, user_account_id: 126, user_account_type: “Member”,
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.

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs