-
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
[Defend Workflows][E2E] Isolate command e2e coverage #154465
[Defend Workflows][E2E] Isolate command e2e coverage #154465
Conversation
# Conflicts: # x-pack/plugins/security_solution/common/endpoint/index_data.ts
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.
Did not have time to complete my review, but here are the comments I have thus far. Will pick this up again tomorrow.
...k/plugins/security_solution/common/endpoint/data_generators/endpoint_rule_alert_generator.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/common/endpoint/data_loaders/index_endpoint_rule_alerts.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/common/endpoint/data_loaders/index_endpoint_rule_alerts.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/common/endpoint/generate_data.ts
Outdated
Show resolved
Hide resolved
...gins/security_solution/scripts/endpoint/agent_emulator/services/endpoint_response_actions.ts
Outdated
Show resolved
Hide resolved
...gins/security_solution/scripts/endpoint/agent_emulator/services/endpoint_response_actions.ts
Outdated
Show resolved
Hide resolved
# Conflicts: # x-pack/plugins/security_solution/public/management/cypress/support/data_loaders.ts # x-pack/plugins/security_solution/public/management/cypress/support/plugin_handlers/endpoint_data_loader.ts # x-pack/plugins/security_solution/public/management/cypress/tasks/index_endpoint_hosts.ts # x-pack/plugins/security_solution/scripts/endpoint/agent_emulator/services/endpoint_response_actions.ts
# Conflicts: # x-pack/test/security_solution_endpoint/apps/endpoint/endpoint_list.ts
Pinging @elastic/security-defend-workflows (Team:Defend Workflows) |
@@ -34,6 +34,7 @@ export const createActionAttachmentUserActionBuilder = ({ | |||
// TODO: Fix this manually. Issue #123375 | |||
// eslint-disable-next-line react/display-name | |||
build: () => { | |||
const actionIconName = comment.actions.type === 'isolate' ? 'lock' : 'lockOpen'; |
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.
Were these changes intentionally done? or a result of perhaps a merge conflict resolution?
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.
Yes, these were done intentionally. Icon type does not propagate to the component correctly for lock
variant, thats why I've used the aria
field that works properly. I will create a PR that fixes this in the UI project. One of the tests from TestRail was about making sure the proper icon is being displayed, hence these changes.
@@ -103,7 +105,7 @@ export async function indexHostsAndAlerts( | |||
} | |||
|
|||
for (let i = 0; i < numHosts; i++) { | |||
const generator = new DocGenerator(random); | |||
const generator = new DocGenerator(random, 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.
Optional: you don't need undefined
as the second argument since the argument is optional
login(); | ||
}); | ||
it('should allow filtering endpoint by Isolated status', () => { | ||
cy.visit('/app/security/administration/endpoints'); |
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.
can you use the rouing method to get the page's path instead of hard coding it:
cy.visit(APP_PATH + getEndpointListPath({ name: 'endpointList' }));
let isolateRequestResponse: ActionDetails; | ||
let releaseRequestResponse: ActionDetails; | ||
|
||
cy.visit('/app/security/alerts'); |
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.
Same here. Please use const APP_ALERTS_PATH
from:
}); | ||
}; | ||
|
||
export const isolateHostWithComment = (comment: string, hostname: 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.
Just wondering if all of these functions (from here down) that are "screen" specific should actually be placed into screens/**
folder since (at least the way I understood it), screens/
is where we would have the methods available to interact with them. I see some perhaps going into a isolation_flyout
and other into a alerts
file.
(FYI: In my pending PR, I have added a screens/alerts.ts
, so if you create that, and depending on which one of us merges first, you might have some merge conflicts)
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.
IMO its better to keep them per test. We usually end up with numerous separated helpers/selectors/actions that for the next person working with them are:
- Really hard to find since these files tend to have hundreds of lines and dozens of different functions
- Tricky in their reusability. Something that works in alerts context might not be reusable when adding alert from different context.
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.
Ok. but I do think that it will just increase code duplication and will likely lead to more maintenance as things change in a specific page. I thought I had read in the cypress docs that this was the suggested best practice: you have your "page helpers" that are Page specific, and then you have your specs which are validating functionality and use the helps depending on what page you are in.
Being that our cypress project really has no suggested guidance on the file/code structure and organization, I guess you (us) can keep it as you see fit 🤷♂️
|
||
import type { ActionDetails } from '../../../../common/endpoint/types'; | ||
|
||
export const interceptActionRequests = ( |
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.
can you please add return types to all of these functions
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.
All these functions have no returns. I tend to separate cy selectors/actions that are being used in multiple places.
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.
No, these have returns, even if it's a void
. Yes, Typescript will infer the return types, but having a explicit return type is best as it not only clarifies to the developer what the function is suppose to return, but also help to ensure that as changes occur inside of a given function, if those break the expected return type, then you get feedback immediately.
IMO, I believe its best to ensure that functions (especially those that are export
'd out) to be property typed, but if you feel strongly it is not necessary, then disregard (although, I will continue to provide this type of feedback in code reviews 😄 ).
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.
Since you have a strong opinion on the matter and I don't, I will add these explicit returns :)
cb: (responseBody: ActionDetails) => void, | ||
alias: string | ||
) => { | ||
cy.intercept('POST', '/api/endpoint/action/*', (req) => { |
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.
can you use a const
for the path here instead of hard coding it?
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.
👍
💚 Build Succeeded
Metrics [docs]Async chunks
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
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.
ResponseOps changes LGTM!
E2E coverage of TestRail "Isolate" suite.
These tests are run against mocked documents. We intercept REST request whenever
Isolate
button is used and mockresponse action response
withsuccess
.