[Uptime] Add unit tests for QueryContext time calculation #56671
Conversation
andrewvc
added
technical debt
|
Pinging @elastic/uptime (Team:uptime) |
andrewvc
added
release_note:skip
| qc.hasTimespan = mockHasTimespan; | ||
|
|
||
| expect(await qc.dateRangeFilter()).toEqual({ | ||
| bool: { |
There was a problem hiding this comment.
This type of assertion is fine with me if we all agree to use/follow it. I personally would use a snapshot for this type of response. The spirit of the snapshot is that, I have evaluated its contents and I know it's what I want in the initial write. After that it should never change unless the module's expected output changes. It results in cleaner-looking test files IMO. But this assertion is effectively the same thing as what a snapshot does, so really it's a semantic preference more than anything else. I am fine either way; if this is more helpful for evaluating what's going on in the test we should do it.
There was a problem hiding this comment.
I think my preference goes the other way. If the output of timespanClause() changes, this test will still work and no snapshot will need to be updated. This test isn't testing timespanClause, there's a dedicated test for that, so changes to the logic there shouldn't affect the pass/fail nature of the test here.
Would you disagree that this property is a benefit?
There was a problem hiding this comment.
That's a pretty good point, I do agree that in this case we don't necessarily want to test the output of functionality that's tested elsewhere.
| const makeQueryContext = () => { | ||
| return new QueryContext({}, rangeStart, rangeEnd, pagination, null, 10); | ||
| }; | ||
| beforeEach(() => (qc = makeQueryContext())); |
There was a problem hiding this comment.
| beforeEach(() => (qc = makeQueryContext())); | |
| beforeEach(() => (qc = new QueryContext({}, rangeStart, rangeEnd, pagination, null, 10))); |
Could we just instantiate a new context directly here, since makeQueryContext isn't referenced anywhere else in the file?
There was a problem hiding this comment.
Yes, I left it there as a style preference, since I thought we might use it in the future, but I think you're right and YAGNI applies here.
| range: { | ||
| 'monitor.timespan': { | ||
| // end date minus 5m | ||
| gte: new Date(Date.parse(rangeEnd) - 5 * 60 * 1000).toISOString(), |
There was a problem hiding this comment.
This seems to me like it will be ok, we're simply modifying a constant value, not computing any relative time.
I view these types of assertions with healthy skepticism always. 😅
There was a problem hiding this comment.
Yeah, the idea with using math here instead of a writing it out was to communicate the semantic intent and also to allow the value at the top of the file to change without breaking the test if that's useful for a future test.
There was a problem hiding this comment.
++ I agree with the implementation. I just look at anything with date manipulation 3x more than the rest of the code in a given diff 😆
| describe('when hasTimespan() is true', () => { | ||
| it('should create a date range filter including the timespan', async () => { | ||
| const mockHasTimespan = jest.fn(); | ||
| mockHasTimespan.mockReturnValue(Promise.resolve(true)); |
There was a problem hiding this comment.
| mockHasTimespan.mockReturnValue(Promise.resolve(true)); | |
| mockHasTimespan.mockReturnValue(true); |
I don't think we need the Promise.resolve.
There was a problem hiding this comment.
Are you sure? That function is async, so should always return a promise.
| describe('when hasTimespan() is false', () => { | ||
| it('should only use the timestamp fields in the returned filter', async () => { | ||
| const mockHasTimespan = jest.fn(); | ||
| mockHasTimespan.mockReturnValue(Promise.resolve(false)); |
There was a problem hiding this comment.
| mockHasTimespan.mockReturnValue(Promise.resolve(false)); | |
| mockHasTimespan.mockReturnValue(false); |
I think it's ok to just return the boolean here.
| range: { | ||
| 'monitor.timespan': { | ||
| // end date minus 5m | ||
| gte: new Date(Date.parse(rangeEnd) - 5 * 60 * 1000).toISOString(), |
There was a problem hiding this comment.
++ I agree with the implementation. I just look at anything with date manipulation 3x more than the rest of the code in a given diff 😆
| qc.hasTimespan = mockHasTimespan; | ||
|
|
||
| expect(await qc.dateRangeFilter()).toEqual({ | ||
| bool: { |
There was a problem hiding this comment.
That's a pretty good point, I do agree that in this case we don't necessarily want to test the output of functionality that's tested elsewhere.
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
) Add Unit tests for the QueryContext class that was missing testing. This would have caught elastic#56612
* master: (42 commits) Move kuery_autocomplete ⇒ NP (elastic#56607) [ML] Functional tests - stabilize job row and analytics result view assertions (elastic#56595) [Discover] Inline angular directives only used in this plugin (elastic#56119) [Discover] Migrate get_sort.js test from mocha to TypeScript (elastic#56011) [SIEM] Enable flow_target_select_connected unit tests (elastic#55618) Start consuming np logging config (elastic#56480) [SIEM] Add eslint-plugin-react-perf (elastic#55960) Mention changed SAML ACS endpoint URL in breaking changes doc. (elastic#56613) Add `getServerInfo` API to http setup contract (elastic#56636) Updates Monitoring alert Jest snapshots Kibana property config migrations (elastic#55937) Vislib replacement toggle (elastic#56439) [Uptime] Add unit tests for QueryContext time calculation (elastic#56671) [SIEM][Detection Engine] Critical blocker, fixes pre-packaged rule miscounts Upgrade EUI to v18.3.0 (elastic#56228) [Maps] Fix server log (elastic#56679) [SIEM] Fixes FTUE when APM node is present (elastic#56574) [Reporting/FieldFormats] expose `setFieldFormats` and call from ReportingPlugin.start (elastic#56563) Update EMS API urls for production (elastic#56657) Ability to delete alerts even when AAD is out of sync (elastic#56543) ...
…56718) Add Unit tests for the QueryContext class that was missing testing. This would have caught #56612 Co-authored-by: Elastic Machine <[email protected]>
Add Unit tests for the QueryContext class that was missing testing. This would have caught #56612