-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Allow toMatchObject to match recursively on any depth of an object #3326
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks! If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact [email protected] if you have any questions. |
CLA Signed. Could you kindly revalidate @facebook-github-bot? |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Pheww.. I'm not sure this is a good idea. This seems way too relaxed to me, tbh. Is there any real world example that makes this a good idea? |
We can ask @ismay or other people from #2506 and related issues :) I just thought that it'll be a good place to start getting familiar with the codebase for me. It indeed seems a little bit too relaxed, but it can be used as an additional feature/extension of an API and not the default behavior of |
Hey @kamilogorek, I think indeed that this is a bit too much. I appreciate though that you are contributing – if you'd like to pick another task for something that is less controversial, please feel free to join our discord channel (see the help section on the website) and ping me there and we'll find something good :) |
@cpojer I definitely will once I get back from my vacations in May! :) Cheers! |
@cpojer I know that this PR was closed a while ago, but you were challenging the author @kamilogorek on a real-life example for when this change may be useful. I am currently migrating test code from a project that's using Chai/Sinon to purely use Jest instead, both for test expectations and mocking. Some of the tests are using Chai's In my particular case, I am testing an object in our API Middleware layer. The return object has a key called expect(mockObject).calledWithMatch({
meta: {
statusCode: 500,
},
}); When I switch from a Sinon to a Jest mock (via expect(mockObject).toBeCalledWith(expect.objectContaining({
meta: {
statusCode: 500,
},
})); Unfortunately, the test fails because of other keys that are in the I believe that this additional information is fruitful enough to revive a healthy conversation about this proposed change. I'd love to hear what you think. Thanks a bunch. |
I have the exact same use-case that @ecbrodie is mentioning. I am testing fetch() calls with large POST body payloads. Most of these payloads is irrelevant to my individual test cases and I don't want to repeat it in every test. It would be incredibly useful to be able to match subsets. |
Is there any progress on this? It would be helpful especially in cases such as the one mentioned by @ecbrodie |
I'm interested in support for nested matchers too. My use case is that I'm wanting to check parts of a request object that's being logged, eg: expect(logger.info).toHaveBeenLastCalledWith(
expect.objectContaining({
env: 'production',
accountId,
req: expect.objectContaining({
method: HttpMethod.POST,
url: ApiService.TPAN_UPLOAD_ROUTE,
headers: expect.objectContaining({
"x-amzn-trace-id": "some-alb-generated-trace-id",
"x-forwarded-proto": "https",
"x-forwarded-for": "some_client_ip"
})
})
}),
expectedMessage
); Without this I need to do dig through the functions |
Doesn't that work now that we have asymmetric matchers? |
Hmm, I tried to create a standalone example to reproduce the problem but it worked, and when I went back and modified my code to use Here's the simple test example that shows it's all good: it('test nested match', () => {
const testFn = jest.fn();
const nestedArg = {
topLevel: 'value1',
topLevel2: 'ignored',
parent: {
child1: 'value2',
child2: {
grandChild1: 'value3',
grandChild2: 'unimportant'
},
child3: 'ignored'
}
};
testFn(nestedArg);
expect(testFn).toHaveBeenLastCalledWith(
expect.objectContaining({
topLevel: 'value1',
parent: expect.objectContaining({
child1: 'value2',
child2: expect.objectContaining({
grandChild1: 'value3',
grandChild2: expect.any(String)
})
})
})
);
}); |
@pedrottimark thoughts on the feedback above? EDIT: there is #6184 which might address it? |
@markmsmith /cc @ecbrodie @peterstarling @fubhy
Yes, this is a realistic use case to improve the report when If you rewrite as Here is a verbose pattern that you can improve by writing a helper function: it('test nested match', () => {
const testFn = jest.fn();
// Do whatever with mock function (for example, receive a request)
expect(testFn.mock.calls.length).toBe(1); // or whatever
expect(testFn.mock.calls[0].length).toBe(1); // or whatever
expect(testFn.mock.calls[0][0]).toMatchObject({
topLevel: 'value1',
parent: {
child1: 'value2',
child2: {
grandChild1: 'value3',
grandChild2: expect.any(String)
},
},
});
}); For more information, see: |
Yeah, that's the form I had re-written it to when I was having trouble. I can add a comment to #6184 with this use case in support of improving |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
Allow the user to recursively match a subset of an object, no matter where it lives in the base object.
For example:
Resolves #2506
Test plan