-
-
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
Throw on incorrect property matchers usage #7128
Comments
I agree this is odd! I wonder if this makes more sense as an eslint rule? |
FWIW the current behavior was what was proposed but I agree that it makes sense to only allow asymmetric matchers now that it's better understood π |
I like the current behaviour, if you have a big response from an api that you want to snapshot and the only thing that changes is a date, then you only need to specify the only field that changes. |
@ellipticaldoor we would keep that but would add the requirement that you specify a matcher const user = {
name: 'Pete Davidson',
createdAt: Date.now(),
id: uuid(),
};
// BAD, properties must be a matcher
expect(user).toMatchSnapshot({
createdAt: 'mocked-date',
id: 'gen-id',
});
// GOOD
expect(user).toMatchSnapshot({
createdAt: expect.any(Date),
id: expect.any(String),
}); |
This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days. |
This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one. |
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. |
π Feature Proposal
I'd like to propose a new behavior to recently introduced "snapshot property matchers" β throwing when the object values are not asymmetric matchers.
We should also link to the guide from
expect.toMatchSnapshot
docs to avoid confusion (regardless this request is accepted or not).Motivation
I've seen this code in the wild:
Which doesn't make much sense (maybe it is sometimes, but not really), because the snapshot file is going to have this very information anyway, resulting in duplicating code and reviewing effort. Such code can easily be replaced with
toMatchObject
ortoMatchSnapshot
without property matcher.Example
We could throw something like:
Pitch
It's an update to core matcher.
cc @rickhanlonii
The text was updated successfully, but these errors were encountered: