-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
fix addd to case relative #117487
fix addd to case relative #117487
Conversation
@elasticmachine merge upstream |
Pinging @elastic/uptime (Team:uptime) |
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.
Thanks for the PR @shahzad31!
The code LGTM, my only concern is with regards to the tests. I will not mark this as "request changes" because I think it would be useful to consider that I'm not fully up-to-speed on the team's position with regards to testing, so I will not block because of that.
However, I think it would still be nice to have tests for these changes.
With regards to the smoke test, here is what I've done:
- Open the exploratory view
- Add a series with a small relative range (using a few seconds ago as the final range)
- Apply the changes to the graph and save it to a case
- Refresh the case multiple times to ensure that the added graph still maintains the absolute time
You can see this on the GIF below.
Please let me know if any further testing is needed.
I've also confirmed that the "Add To Case" button disappears when no time-series exist.
{timeRange && ( | ||
<EuiFlexItem grow={false}> | ||
<AddToCaseAction lensAttributes={lensAttributes} timeRange={timeRange} /> | ||
</EuiFlexItem> | ||
)} |
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'd suggest adding a test to confirm that this action shows/hides depending on the value of timeRange
.
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.
well, i think testing a simple condition doesn't make sense, if this condition was based on complex logic, it makes sense. A simple boolean condition, which hides/shows a dom element. I don't think it adds any value in terms of testing.
const { createCaseUrl, goToCreateCase, onCaseClicked, isCasesOpen, setIsCasesOpen, isSaving } = | ||
useAddToCase({ | ||
lensAttributes, | ||
getToastText, | ||
timeRange, | ||
timeRange: { from: absoluteFromDate.toISOString(), to: absoluteToDate.toISOString() }, |
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.
Similarly, here I think we could we could add a test to ensure that these are passed as absolute dates to addToCase
. In the test we could either check for the correct absolute dates on the URL (which would, in my opinion, be the most straightforward and decoupled option), or we could check the parameters passed to the hook itself (which I don't really like as it tightly couples the test with the implementation).
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.
@lucasfcosta added a test case 274ebac
(#117487)
@elasticmachine merge upstream |
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.
Thanks for adding that test! 🙌
I added a tip there in case you want to follow it, but please feel free to go ahead and merge as I understand there may be time constraints on this. I don't want to block because of the mock.
@@ -21,6 +24,31 @@ describe('AddToCaseAction', function () { | |||
expect(await findByText('Add to case')).toBeInTheDocument(); | |||
}); | |||
|
|||
it('should parse relative data to the useAddToCase hook', async function () { | |||
const useAddToCaseHook = jest.spyOn(useCaseHook, 'useAddToCase'); | |||
jest.spyOn(datePicker, 'parseRelativeDate').mockReturnValue(moment('2021-11-10T10:52:06.091Z')); |
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.
Thanks for adding this test! It LGTM.
As a nit in case you want a tip: I think here we're kinda losing some value by mocking early on parseRelativeDate
. Instead we could mock the global timers setting a fixed date and then the parsed dates in timeRange
would always be the same, but they would indeed be now
and 5 minutes ago
.
Currently, both dates are the same as we always return the same mock.
I won't block because of this though, just a tip in case you want the test to be closer to runtime behaviour.
In case you wanna read more about timers I'd recommend this link. Alternatively you can use jest-when
for returning different values for the passed dates, but then I think we end-up in the same place as before as it's still a tightly coupled mock.
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @shahzad31 |
The following labels were identified as gaps in your version labels and will be added automatically:
If any of these should not be on your pull request, please manually remove them. |
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
Fixes #117008
While adding to case, convert relative dates to absolute while generating params for add to case call to action.