-
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
[Security Solution] Adds Cypress test for index action in detection rules #141069
[Security Solution] Adds Cypress test for index action in detection rules #141069
Conversation
@elasticmachine merge upstream |
@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.
Alright, I ended up posting a ton of comments, sorry about that :)
One general comment: my expectation was that it should be enough to cover action execution at the integration test level - just like it's done for the alerts generation logic for every rule type.
Scenario: Rule executes successfully with added action (1 integration)
But I'm not going to ask to remove this new e2e test - I think it's also good to have one at the e2e level!
x-pack/plugins/security_solution/cypress/e2e/detection_rules/rule_actions.cy.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/cypress/e2e/detection_rules/rule_actions.cy.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/cypress/e2e/detection_rules/rule_actions.cy.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/cypress/e2e/detection_rules/rule_actions.cy.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/cypress/e2e/detection_rules/rule_actions.cy.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/cypress/e2e/detection_rules/rule_actions.cy.ts
Outdated
Show resolved
Hide resolved
runsEvery: getRunsEvery(), | ||
lookBack: getLookBack(), |
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 noticed that runsEvery
equals 1 second by default.
// Default interval is 1m, our tests config overwrite this to 1s
// See https://github.com/elastic/kibana/pull/125396 for details
const getRunsEvery = (): Interval => ({
interval: '1',
timeType: 'Seconds',
type: 's',
});
What's the reason for having such a short interval?
I think for most of the tests where we need to run a rule, we need to run it only once in order to verify something. This means we could set the interval to a large value like 24 hours.
If we use a very short interval in e2e tests, this can:
- create unnecessary load (Alerting Framework needs to schedule rules all the time while tests are running)
- introduce unexpected race conditions between a test and Kibana running and re-running rules in the background
- ultimately make the tests more flaky
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 don't remember why we did it like that, originally for sure that was a reason behind. Good to have revisited this then :)
description: rule.description, | ||
interval: `${rule.runsEvery.interval}${rule.runsEvery.type}`, | ||
from: `now-${rule.lookBack.interval}${rule.lookBack.type}`, | ||
interval: `${rule.runsEvery?.interval}${rule.runsEvery?.type}`, |
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 will render it to undefinedundefined
if rule.runsEvery
is nullable. This is why I'm skeptical about making most of the rule fields optional in the CustomRule
interface.
const riskScore = rule.riskScore != null ? parseInt(rule.riskScore, 10) : undefined; | ||
const severity = rule.severity != null ? rule.severity.toLocaleLowerCase() : undefined; |
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.
And we also have to check those fields for null all the time...
export const deleteConnectors = () => { | ||
const kibanaIndexUrl = `${Cypress.env('ELASTICSEARCH_URL')}/.kibana_\*`; | ||
cy.request('POST', `${kibanaIndexUrl}/_delete_by_query?conflicts=proceed`, { | ||
query: { | ||
bool: { | ||
filter: [ | ||
{ | ||
match: { | ||
type: 'action', | ||
}, | ||
}, | ||
], | ||
}, | ||
}, | ||
}); | ||
}; |
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.
It would be great to extract all API calls from this common
file to the corresponding files under x-pack/plugins/security_solution/cypress/tasks/api_calls
…ule_actions.cy.ts Co-authored-by: Dmitrii Shevchenko <[email protected]>
…ule_actions.cy.ts Co-authored-by: Dmitrii Shevchenko <[email protected]>
…-ref HEAD~1..HEAD --fix'
@xcrzx @banderror lots of thanks for your thorough revision!!! :) I believe it has helped a lot to put the focus on some pain points we have in general that need to be tackled in order to have a more robust and maintainable test suite. I'll write a ticket to collect all this information and I'll share it with you to gather more ideas. Thanks! |
…ule_actions.cy.ts Co-authored-by: Dmitrii Shevchenko <[email protected]>
@elasticmachine merge upstream |
@elasticmachine merge upstream |
merge conflict between base and head |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Page load bundle
History
To update your PR or re-run it, just comment with: |
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.
The test now looks perfect, and thank you @MadameSheema for addressing so many comments!
I'll write a ticket to collect all this information and I'll share it with you to gather more ideas.
Please do, that would be awesome!
I'd like us to have ticket(s) for the following ideas:
- Reusing existing rule schema in Cypress tests (comment)
- Making tests driven by code instead of data; getting rid of optional properties in data (comment, comment, comment)
- Cleaning up duplicate properties in data (comment, comment)
- Setting a large default rule interval (comment)
- Extracting some code from
tasks/common
into separate files (comment)
Let me know if I can help with writing them.
…ules (elastic#141069) Co-authored-by: Dmitrii Shevchenko <[email protected]> Co-authored-by: Kibana Machine <[email protected]> (cherry picked from commit db6a825)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…ules (#141069) (#142227) Co-authored-by: Dmitrii Shevchenko <[email protected]> Co-authored-by: Kibana Machine <[email protected]> (cherry picked from commit db6a825)
Summary
In this PR we are adding a test to validate that an index action can be added during the rule creation and that the action is properly triggered.
In order to do that, we have extended the
object/connectors.ts
file creating a new interface, calledIndexConnector
, which contains all the information needed to create an index connector. We have also created the Connectors type that would be used when creating a rule with actions.In this test we are creating the rule from the UI to include also the creation of the action. The main focus of the test is to check that the action works correctly, that is why we don’t need a rule with all the fields, we just need a rule with the mandatory field needed on the UI to make also the test execution faster.
To be able to have a rule with just the UI mandatory fields, we have refactored the
CustomRule
interface to make optional some of the current fields, forcing us to refactor also the methods where some of those fields are used. A part from the refactor, we have extended the interface, with the Actions field.The new test performs the following actions: