Sinon: Deep Equal should not exact equal for error

Created on 9 Mar 2017  ·  3Comments  ·  Source: sinonjs/sinon

Hi Sinon! Thank you for providing awesome library with cool new features added to the pre-release version. I have been using pre for newly introduced API (I was going to write extension myself and I found the code whiling digging through the source) but .6 release broke our large test suite.

  • Sinon version : 2.0.0-pre.6
  • Environment : macOS with Node6+
  • Example URL :
  • Other libraries you are using:
    Mocha, Babel

What did you expect to happen?
I did not expect .deep.equals assertion to fail when different but "equal" instance of error was passed
What actually happens
For any subclass of Error, deep equals does exact equals. https://github.com/sinonjs/sinon/blob/master/lib/sinon/util/core/deep-equal.js#L54-L56

Medium Help wanted stale

Most helpful comment

Hi everyone!

This is indeed something simple to solve and I'm willing to do a PR for it. However, I'd like to suggest a different approach other than just fixing that if clause.
In Chai we've got a module called deep-eql which does deep equality checks. It has been extensively tested and fine tuned for performance and works fine on Chai's core.

By adopting the same library we would also be working on the same codebase in the future in order to improve it and make it better for every project using it.

Also, it still allows us to have the use method due to the comparator argument this library accepts.

If you don't want to adopt it it's fine too, but I just thought about suggesting it before solving this issue.

All 3 comments

Hi everyone!

This is indeed something simple to solve and I'm willing to do a PR for it. However, I'd like to suggest a different approach other than just fixing that if clause.
In Chai we've got a module called deep-eql which does deep equality checks. It has been extensively tested and fine tuned for performance and works fine on Chai's core.

By adopting the same library we would also be working on the same codebase in the future in order to improve it and make it better for every project using it.

Also, it still allows us to have the use method due to the comparator argument this library accepts.

If you don't want to adopt it it's fine too, but I just thought about suggesting it before solving this issue.

@lucasfcosta I like the proposed solution. It might be a bit of challenge to wrangle match to become a comparator option ... but it looks like you like the challenges ;)

I would love to see a PR that reduces the size of the codebase

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings