-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Uptime] Update Ml functional test #62562
Conversation
Pinging @elastic/uptime (Team:uptime) |
@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.
Had a few comments and asks for clarification. Thanks for taking the time to write this!
}; | ||
|
||
return { | ||
async openMLFlyoutOrMenu() { |
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'm struggling to understand what's happening here. Why would we want to test only one of the two options, wouldn't this mean the outcome of the test could be different on subsequent runs but still pass?
} | ||
}); | ||
|
||
it('open ml flyout or menu', async () => { |
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 commented on the function in the uptime service, but based on the code it seems like this test could have more than one expected outcome, which seems strange to me.
}); | ||
|
||
it('can create and delete ML anomaly job', async () => { | ||
if (await uptime.ml.alreadyHasJob()) { |
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 think we could simplify this, by just having
if (await uptime.ml.alreadyHasJob()) {
await uptime.ml.deleteMLJob();
}
await uptime.ml.createMLJob();
await uptime.navigation.refreshApp();
await uptime.ml.deleteMLJob();
Then the test will always have the same outcome.
this.setStatusFilterDown(); | ||
} | ||
|
||
return true; |
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.
Is it necessary to return true
if we're never going to return a different result? Promise<void>
seems more appropriate.
const retry = getService('retry'); | ||
const log = getService('log'); | ||
|
||
const alreadyHasJob = async () => { |
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.
Is there a reason the contents of this function can't live in the exported function below that is calling it?
}); | ||
}, | ||
async canCreateJob() { | ||
return !!(await (await testSubjects.find('uptimeMLCreateJobBtn')).getAttribute('disabled')); |
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.
return !!(await (await testSubjects.find('uptimeMLCreateJobBtn')).getAttribute('disabled')); | |
const createJobBtn = await testSubjects.find('uptimeMLCreateJobBtn'); | |
return !!await createJobBtn.getAttribute('disabled'); |
I think breaking this up to two lines will make it easier to understand what is happening.
await testSubjects.existOrFail('uptimeOverviewPage', { timeout: 2000 }); | ||
// Check if are already on overview uptime page, we don't need to repeat the step | ||
await retry.tryForTime(60 * 1000, async () => { | ||
if (await testSubjects.exists('uptimeSettingsToOverviewLink', { timeout: 0 })) { |
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.
if (await testSubjects.exists('uptimeSettingsToOverviewLink', { timeout: 0 })) { | |
if (await testSubjects.exists('uptimeSettingsToOverviewLink')) { |
That parameter is optional, if we aren't specifying a timeout anymore it's not needed.
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.
if we don't specify timeout 0, it uses default timeout from config.
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.
Ah ok.
if (await testSubjects.exists('uptimeSettingsToOverviewLink', { timeout: 0 })) { | ||
await testSubjects.click('uptimeSettingsToOverviewLink'); | ||
await testSubjects.existOrFail('uptimeOverviewPage', { timeout: 2000 }); | ||
} else if (!(await testSubjects.exists('uptimeOverviewPage', { timeout: 0 }))) { |
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.
} else if (!(await testSubjects.exists('uptimeOverviewPage', { timeout: 0 }))) { | |
} else if (!(await testSubjects.exists('uptimeOverviewPage'))) { |
Same comment as above.
) { | ||
throw new Error('Expected monitor name not found'); | ||
checkIfOnMonitorPage: async (monitorId?: string) => { | ||
const monitorPage = await testSubjects.exists('uptimeMonitorPage', { timeout: 0 }); |
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.
const monitorPage = await testSubjects.exists('uptimeMonitorPage', { timeout: 0 }); | |
const monitorPage = await testSubjects.exists('uptimeMonitorPage'); |
(await testSubjects.getVisibleText('monitor-page-title')) !== monitorName | ||
) { | ||
throw new Error('Expected monitor name not found'); | ||
checkIfOnMonitorPage: async (monitorId?: string) => { |
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.
checkIfOnMonitorPage: async (monitorId?: string) => { | |
checkIfOnMonitorPage: async (monitorId: string) => { |
Any reason we can't require this parameter?
@justinkambic took care of your feedback. |
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.
LGTM
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* update test * added test * updated type * updated test * updated test * update test Co-authored-by: Elastic Machine <[email protected]>
* update test * added test * updated type * updated test * updated test * update test Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Summary
Fixes: #60963
Added functional test for ML
Testing
This doesn't change any functionality, basically if CI is good, this should be good to go.