-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(std/testing): Add support for object assertion against object subset #8001
Conversation
Thanks for the contribution @lowlighter! Is there some prior art for this assertion? @nayeemrmn PTAL |
std/testing/asserts.ts
Outdated
actual: { [key: string]: unknown }, | ||
expected: { [key: string]: unknown }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should symbols be allowed?
Yes, it's heavily inspired from expect.toMatchObject(object) from Jest JavaScript testing framework, though implementation may differ a bit. Since a lot of logic has already been done in
Yes, I'll add them and add tests to cover them ! |
@lowlighter thanks, that sounds good to me. I'll wait for @nayeemrmn's review before landing |
std/testing/asserts.ts
Outdated
// and filter recursively on object references | ||
const filtered = {} as loose; | ||
for ( | ||
const [key, value] of Object.entries(a).filter(([key]) => key in b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think Object.entries()
includes symbols. This would be shown if the tests included an erroneous case for symbols. You can use [...Object.getOwnPropertyNames(a), ...Object.getOwnPropertySymbols(a)]
to get a complete list of keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I replaced Object.entries()
with your suggestion and it works like a charm, and changed string|symbol
by PropertyKey
which seems more accurate.
I got some trouble with using symbol
as index signature so I casted them into string
but not sure it's the cleanest way...
I wanted to add an erroneous case like you suggested, but seems that assertEquals
does not handle symbol
s perfectly currently (unless I missed something) :
import { assertEquals } from "https://deno.land/std/testing/asserts.ts"
const foo = Symbol("foo")
Deno.test("symbol1", () => assertEquals({[foo]:"bar"}, {[foo]:"bar"}))
Deno.test("symbol2", () => assertEquals({[foo]:"bar"}, {[Symbol("foo")]:"bar"}))
running 2 tests
test symbol1 ... ok (2ms)
test symbol2 ... ok (1ms)
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (4ms)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks @lowlighter
…bset (denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
…denoland/deno#8001) This commit add supports for a new assertion function "assertObjectMatch" which allows to test an actual object against an expected object subset (i.e. inclusivity, not equality).
This add supports for a new assertion function
assertObjectMatch
which allows to test anactual
object against anexpected
object subset (i.e. inclusivity, not equality)Why ?
It's often useful to test an object partly without testing the remaining properties (like for web api response, where you might want to only check a few fields).
This function filters out
actual
object withexpected
object subsets keys before callingassertEquals
(so it's actually a wrapper which acts as a syntaxic sugar).