Repository navigation
Proposal: assert.matchObject #50399
Description
Activity
/cc @nodejs/assert. This doesn't seem like a bad idea to me.
Reacted by Gerardo Limaso the difference between this and
deepEqualis just that it only checks present properties on the "actual" against the "expected"? could this just be an option to deepEqual?so the difference between this and deepEqual is just that it only checks present properties on the "actual" against the "expected"?
yes.
could this just be an option to deepEqual?
Well, I guess so, but i'm more convinced that it should be the same as many other testing frameworks as a dedicated method.
To me "assert to match object" is really not something I could understand without reading its docs, so I would prefer if we picked a different name. I think adding
allowSupersetoption todeepStrictEqualor something like that would make the most sense, and we can always expose an alias later if we feel the need (just my two cents, feel free to disagree). PRs welcome :)Reacted by Arthur Fiorette, Jordan Harband and Francis Gulotta+1 on that.
assert.throwsalready supports something similarcould this just be an option to deepEqual?
imo no. the current signature of deepEqual is
assert.deepEqual(actual, expected[, message]), and if we were to maintain backwards compatibility, we would need to add the option after message. but in order for people to use this new option, they would be required to define a message which they may not want to.A way to make this would would require a soft breaking change with a new signature of:
deepEqual<T>(actual: unknown, expected: T, messageOrOption?: string | { message?: string; superset?: boolean; })
Reacted by Ruben Bridgewater@aduh95 I agree matchObject isn't a great name if it were to work with arrays (as does jest toMatchObject), but I also don't like adding an option to deepStrictEqual for the same reason as my previous comment.
How about
deepSupersetStrictEqual? We still want the primitives to be compared using===. Maybe never add legacydeepSupersetEqualtonode:assertbut only add it tonode:assert/strict?I think it would be fine to make the optional third argument an options object if not a string, as you suggested - and will ensure future compatibility for additional options.
"superset" is a confusing name for this behavior; "allowExtraProperties", maybe?
Just extending the
deepStrictEqualinto this signature would not result in a breaking change:function deepStrictEqual<T>(actual: unknown, expected: T, message?: string | Error): asserts actual is T; function deepStrictEqual<T>(actual: unknown, expected: T, options?: { superset?: boolean }, message?: string | Error): asserts actual is T;
I'm still not sure if an attribute would have a better DX:
// attribute assert.deepStrictEqual( obj, { a: 1, b: 2 }, { superset: true } ); // custom method assert.deepSupersetEqual(obj, { a: 1, b: 2 });
37 remaining items
- added a commit that references this issue
on Nov 23, 2024 - added a commit that references this issue
on Nov 26, 2024 - added a commit that references this issue
on Jan 5, 2025
What is the problem this feature will solve?
(I tried searching for related issues, but couldn't find one, sorry if this is a duplicated)
One thing I miss when using
node:testandnode:assertfromjestrelated tests is theexpect(A).toMatchObject(B)api. Within large production systems, a we usually have large objects with multiple deep properties, withassert.matchObjectwe could test the same way asassert.deepStrictEqual, but only specifyingexpectedproperties we want to test out with a much nicer DX. Obviously aassert.notMatchObjectshould also be present.Current behavior:
What is the feature you are proposing to solve the problem?
With
assert.matchObject:It should ensure equality only for properties assigned to the second parameter.
myObjectToTestcould have 10000 other attributes or be literally the same as the second parameter, it would pass. Whenever a property declared inside the second object is not present in the first one, anAssertionErrorshould be thrown.Of course this is a small example that could be tested separately, but it is a perfect DX fit for large objects.
What alternatives have you considered?
I'm creating this feature request with a jest like API in mind, however any alternatives that also fixes this problem are welcome :) I'm also open to working on this, but first I need some kind of guidance :)