Proposal: Ability to exclude property from `deepEqual` #885

Open
sanex3339 opened this Issue Dec 13, 2016 · 4 comments

Projects

None yet

4 participants

@sanex3339
sanex3339 commented Dec 13, 2016 edited

For example a have two AST trees, each node of these AST trees has uniqueId property which is random string.

Now i want to deep equal this AST trees and equal fails because uniqueId properties are not the same.

So, it would be nice to describe in deepEqual array with property names which would be ignored during deepEqual

deep-equal

@lucasfcosta
Member

Hi @sanex3339, thanks for you issue!

Your request seems to make sense to me, even though you could simply traverse the whole object using Object.getOwnPropertyNames + Object.getPrototypeOf that would be too much work in a single test.

But, when thinking about how we would do that I'm not sure there will be a clean way to create such an assertion. The only acceptable syntax that comes to my mind is expect(objOne).to.be.deepEqual(objTwo).exceptFor('keyName') but unfortunately we wouldn't be able to apply exceptFor to the deepEqual assertion since it comes later.

IMO that would be an useful feature to have, but only if we had a clean way of expressing that through code.

If anyone has a better idea or disagrees, please share your thoughts 😄

@sanex3339
sanex3339 commented Dec 13, 2016 edited

Sadly i can't help with brain storm, but it would be amazing if this feature will be implemented (with assert interface).

@shvaikalesh
Member

Hey @sanex3339, thanks for the proposal.

I've tried using Chai's .deep.equal to compare ASTs and strongly feel that exclude property would be of much help to ignore whitespaces (PostCSS's raws) and sources. So definitely 👍 .

On implementation: we can add options object as second parameter to .equal.

@keithamus
Member

FWIW I think this might be a kind of duplicate of #644. Part of the work with deep-eql's recent huge refactoring was to enable these kind of behaviour alterations within the deep-eql algo. The plan in #644 is different but I'd like to see some more discussion around that. I won't close this one, but let's keep both in mind when discussing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment