jasmine: .toEqual fails for objects with the same members but of different types

it("should tell me what's the difference between these 2", function () {
  function A() { this.a = 10; }
  function B() { this.a = 10; }
  expect(new A()).toEqual(new B());
});

fails, but it does not say why - it only states: Expected { a : 10 } to equal { a : 10 }. which is instead true.

About this issue

  • Original URL
  • State: closed
  • Created 10 years ago
  • Comments: 19 (6 by maintainers)

Commits related to this issue

Most upvoted comments

At least in TypeScript spread operator can be also used to instead of Object.assign for cleaner syntax: expect({...objOfTypeA}).toEqual({...objOfTypeB});

@slackersoft can adding an expect(obj).toDeepEqual(expected) matcher to Jasmine be considered at all? seems like a common use case for expect(someFunction()).toDeepEqual({a: b}) kind of things, where constructor of the returned object does not matter

@dinvlad objectContaining doesn’t look at constructors when comparing, so the Object.assign calls shouldn’t do anything. I think the initial request was to do an exact property match which would look more like:

expect(Object.assign({}, objOfTypeA)).toEqual(Object.assign({}, objOfTypeB));

Which makes me think what we might want is something like a jasmine.objectWithProperties asymmetric matcher which explicitly ignores constructors.

Is there any way to compare the properties of an object and ignore differences in constructor function? I.e. something like deepEqual() in Chai or _.isEqual() in Underscore/Lodash, which is how I assumed toEqual() would work from reading its docs…

When using JS-style “duck typing” you often don’t care about the specific constructor, just which properties the object has after it’s created.

You can make use of jasmine-equal-value

I agree that it would be useful to have some way to deeply compare two objects that doesn’t check their constructors (or maybe not any constructors). I’m not sure the best way to get that into Jasmine right now or what exactly to call it.

Because the existing toEqual does a deep compare, I think another matcher called toDeepEqual would be confusing. It would also probably be nice to be able to use some of the rest of the deep compare code that is already in effect there.

I’m open to other ideas/names/PRs for something like this.