Add functional tests for creating alerts / SLOs #178744
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
thomheymann
added
release_note:skip
|
Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs) |
x-pack/test/functional/apps/observability_logs_explorer/alerts.ts
Outdated
Show resolved
Hide resolved
...gins/observability_solution/observability_logs_explorer/public/components/alerts_popover.tsx
Outdated
Show resolved
Hide resolved
|
Although is almost duplicated code, could you also add the same tests for the serverless test suite please? |
...k/test_serverless/functional/test_suites/observability/observability_logs_explorer/alerts.ts
Outdated
Show resolved
Hide resolved
…-explorer-alerts-tests
…omheymann/kibana into 46-logs-explorer-alerts-tests
| @@ -30,7 +30,8 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) { | |||
| expect(toastTitle).toMatch(/created/i); | |||
| }); | |||
|
|
|||
| it('should create SLO successfully', async () => { | |||
| // Flaky test | |||
| it.skip('should create SLO successfully', async () => { | |||
There was a problem hiding this comment.
question: why is this test marked as flaky? Does it make sense to keep it implemented if will be disabled from the beginning?
There was a problem hiding this comment.
There's an intermittent issue where the good query field does not get populated which stops the form from getting submitted
There was a problem hiding this comment.
Is there anything we can do about this case? Having a flaky test disabled since the beginning doesn't bring additional value, you may consider directly removing it if it's not possible to stabilize it.
There was a problem hiding this comment.
Keeping skipped tests preserves their intention, a link to the original PR and failing builds in a very visible way directly in the codebase so it can be picked up again in the future. I think there's value in that.
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
|
Is there any reason for Remove serverless test change back? |
Serverless does not expose internal APIs so there is no programmatic way of deleting the created rules. Functional tests are not isolated so leaving these rules in breaks other tests. Closing this PR to focus on more pressing issues. |
Summary
Functional tests for #175777 and #176024