0

How can two objects seem to be identical but are not?

Have pickle_step that runs code "model!(owner).send(association).should == model!(target)"

When run in a tag (cucumber --tags @thisonescenario), owner and target are the same and the test passes.

When ran with rest of scenarios (cucumber), the owner and target are not the same.

After inspection (rdebug) the code says the classes aren't the same even though they really seem to be. Output of cucumber step is as follows:

  expected: #<Content _id: content_1, _type: nil>
       got: #<Content _id: content_1, _type: nil> (using ==)
  Diff: (RSpec::Expectations::ExpectationNotMetError)

Note: == overloaded by Mongo library with code below:

def ==(other)
  self.class == other.class &&
  attributes["_id"] == other.attributes["_id"]
end

The _id comparison is true. The self.class == other.class is false.

Inspection of classes properties such as descendants, ancestors, etc. show they are the same.

Any ideas?

ehsk
  • 99
  • 9
  • Thank you for the information. It was a misunderstanding on my part on how stack overflow works. I've gone through and did the accept answer thing. – ehsk Jul 15 '11 at 03:46
  • Cool, now the `self.class == other.class` should be comparing `self.class.object_id` with `other.class.object_id` - can you output those in your debug/test and see if they're the same? – smathy Jul 15 '11 at 04:02
  • Ya. Those are different when running all scenarios but the same when running just the one scenario. Also, doing a self.class.ancestors and other.class.ancestors shows a different Module (which seems like some random id: # for example. So, at least I can now see that they are in fact different. Thanks for the tip. A quicker way to see if the objects are the exact same. – ehsk Jul 16 '11 at 08:04

1 Answers1

0

What if you use === instead == to compare the classes names?

something like

other === self  && ...
Franco Brusatti
  • 81
  • 1
  • 9
  • That would also match subclasses, which is functionally different, though possibly desirable. – Chuck Jul 14 '11 at 17:39
  • I did try this but the result was all object comparisons failing. I think === does a lot more than just compare and changes it's beahavior not just because of overloading but because of language usage (case statements for example). As an example, you could do (1..5)===3 which is true implying 3 is in 5. I believen the === operator is also the underlying operator for Case statements in ruby. Other examples a = "Hello" a.class === a => a.is_a?(a) b = "Hello" a === b is true a.class === b.class is false => a.class.is_a?(b.class) but a.class == b.class is true – ehsk Jul 15 '11 at 03:55