-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Recurring run details tests #202
Conversation
Pull Request Test Coverage Report for Build 342
💛 - Coveralls |
}, | ||
} as ApiJob; | ||
|
||
historyPushSpy.mockClear(); |
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.
this big block of calls should be reducible using mockReset()
https://jestjs.io/docs/en/mock-function-api.html#mockfnmockreset
"mockReset() does everything that mockFn.mockClear() does, and also removes any mocked return values or implementations.",
-- unless you're just looking to have dummy functions for many of them, but it still seems like calling reset
is preferable to clear
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.
How does mockReset
reduce the calls here?
It seems to me like you either do mockReset
followed by a mockImplementation
call, or you just do mockClear
no?
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 guess it depends on what your intent is with the mockImplementation()
calls. If you're just trying to remove whatever other mock implementation there was, you should use mockReset
, if you actually want there to be an empty implementation, then calling clear
+ implement
is right.
In the cases where you're calling mockClear
without mockImplementation
though, it seems like reset
should be preferable because that way you make sure you remove whatever the previous mocked implementation was
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rileyjbauer The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rileyjbauer The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
update dockerfiles to use ubi images and update go to 1.21
RecurringRunDetails
where an undefinedenabled
field shows both Enable and Disable buttons as active.RecurringRunDetails
.This change is