Closed werkshy closed 2 years ago
It was most likely a side effect pf https://github.com/marchaos/jest-mock-extended/pull/60 Since this was introduced to fix a bug I expect it will stay that way. Strict equality on JS objects that are not primitives is always brittle at best. I would suggest either creating an operator for jest for dates or just comparing the timestamp that underlines the date.
I appreciate your comment @Sytten and thank you to all the contributors. This is a useful package.
If I was just testing the value of createdAt
I could compare the underlying timestamp, but in this case I want to assert on the structure of this query object (Sequelize) that I'm building up. I don't even know how to write an expectation that this part of the object is a proxied Date that matches the expected timestamp.
either creating an operator for jest for dates
I'm not sure what this would look like, can you think of something similar to base that on?
I looked at #60 and I think I may have experienced that bug a few months ago and just lived without the assertion I was trying to make because I couldn't understand the cause at the time. If this new issue isn't a bug, it at least feels like a limitation and it is surprising to me, as a user (the surprise is that I set createdAt
as a Date
, but it was converted into a Proxy
.)
Is there any way to more generally have a Proxy for a Date pass an equality expectation with a Date? If not, maybe I just need to embrace the workaround of setting createdAt: mock<Date>()
in this case.
Maybe you could reduce the strictness level of your assertion like with toMatchObject
, it should pass even if it is a proxy.
To me it is no surprising behaviour since it is within a mock
, otherwise you would need a spy or a partial mock (which are not a thing in this lib right now).
Maybe you could reduce the strictness level of your assertion like with
toMatchObject
, it should pass even if it is a proxy.
🙏 @Sytten thank you! toMatchObject()
works here, and is probably what I should have been using all along. I am going to close this issue since that is the more idiomatic expectation.
I have a test like this that is now breaking because
obj.createdAt
is a Proxy, not a Date after upgrading to 2.0.4. (excuse the indentation, i omitted some irrelevant context)The failure reported is
Workaround: I can get this test to pass by declaring
obj
likebut I don't love this, and other tests may require the date to be a specific value and be comparable to other dates.
Is this a bug? Is there a better way to write the
expect()
that is failing?