feature request: Ability/option to disable dot notation for deep equality when using .toHaveProperty

[dmmulroy]

I am flattening (using flat) deeply nested objects and performing business logic on it based on the flattened keys/values. In example:

const flattenedObject = flatten({ key: 'value', nested: { key: 'value' } });
console.log(flattenedObject); //  { key: 'value', 'nested.key': 'value' }

I would like to test that a key is on my object and has a particular value after being flattened, however because .toHaveProperty uses dot notation for checking deeply nested references I am unable to do so.

Example:

expect(flattenedObject).toHaveProperty('nested.key', 'value');

Fails with:

expect(object).toHaveProperty(path, value)

Expected the object:
{"key": "value", "nested.key": "value"}
To have a nested property:
"nested.key"
With a value of:
"value"

The work around for this is:

expect(flattenedObject['nested.key']).not.toBeUndefined();
expect(flattenedObject['nested.key']).toEqual('value');

Example/testable repository: https://github.com/dmmulroy/jest-toHaveProperty-feature-request

[thymikee]

Since this matcher is already kind of special, maybe it's worth to add a third argument?
E.g.:

expect(flattenedObject).toHaveProperty('nested.key', 'value', {dot: false});

[jseminck]

Is this still a feature that is wanted (since it has Discussion label) ? It seems not too difficult to add this feature, and I would like to make a PR for it. 😄

[thymikee]

I'm for that change. It doesn't break the API and looks like will make your life easier ;)

[jseminck]

One issue I found already is that the current API also supports expect(myObj).toHaveProperty('myKey'), to check whether the key simply exists, not taking into account the value.

But since the options argument has to be the current non-existing third argument, then we can't have that API for when options would be passed...

[thymikee]

this should work?

expect(flattenedObject).toHaveProperty('nested.key', expect.any(), {dot: false});

[aaronabramov]

i was thinking about implementing a support for array arguments, because we store a lot of paths in array constants. like this:

expect({a: {b: {c: 1}}}).toHaveProperty(['a', 'b', 'c'], 1);

your case will look like:

expect({'a.b.c': 1}).toHaveProperty(['a.b.c'], 1);

would that work?

[aaronabramov]

it'll also enable array indexes in paths without crazy [0] annotations.

expect([{a: {b: 1}, null]).toHaveProperty([0, 'a', 'b'], 1);

[DrewML]

Ran into this while testing a webpack plugin, and asserting on the keys of assets, which will all be file names (so they'll all have dots).

I like the idea of using arrays (as @aaronabramov mentioned) instead of dot-paths. FWIW, this is the API that ImmutableJS uses for the getIn and setIn methods.

One other thought: any reason not to have the API try both options? When a string with a . character is present, check if a key in the object exists with an exact string match. If it does, assertion passes (or moves on to validate a match of values). Otherwise, move on to the deep path match.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.