Skip to content
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

Merged
merged 22 commits into from
Apr 24, 2023

Conversation

szwarckonrad
Copy link
Contributor

@szwarckonrad szwarckonrad commented Apr 5, 2023

E2E coverage of TestRail "Isolate" suite.
These tests are run against mocked documents. We intercept REST request whenever Isolate button is used and mock response action response with success.

@szwarckonrad szwarckonrad added release_note:skip Skip the PR/issue when compiling release notes Team:Defend Workflows “EDR Workflows” sub-team of Security Solution v8.8.0 labels Apr 5, 2023
Copy link
Contributor

@paul-tavares paul-tavares left a 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.

# 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
@szwarckonrad szwarckonrad marked this pull request as ready for review April 18, 2023 16:07
@szwarckonrad szwarckonrad requested review from a team as code owners April 18, 2023 16:07
@elasticmachine
Copy link
Contributor

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';
Copy link
Contributor

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?

Copy link
Contributor Author

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);
Copy link
Contributor

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');
Copy link
Contributor

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');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

});
};

export const isolateHostWithComment = (comment: string, hostname: string) => {
Copy link
Contributor

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)

Copy link
Contributor Author

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:

  1. Really hard to find since these files tend to have hundreds of lines and dozens of different functions
  2. Tricky in their reusability. Something that works in alerts context might not be reusable when adding alert from different context.

Copy link
Contributor

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 = (
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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 😄 ).

Copy link
Contributor Author

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) => {
Copy link
Contributor

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?

Copy link
Contributor

@paul-tavares paul-tavares left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
cases 374.3KB 374.3KB +44.0B
Unknown metric groups

ESLint disabled line counts

id before after diff
securitySolution 394 397 +3

Total ESLint disabled count

id before after diff
securitySolution 474 477 +3

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Member

@cnasikas cnasikas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ResponseOps changes LGTM!

@szwarckonrad szwarckonrad merged commit 792c786 into elastic:main Apr 24, 2023
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Apr 24, 2023
szwarckonrad added a commit that referenced this pull request Apr 25, 2023
…rt (#155360)

Depends on #154465

This PR backports `isolate` command e2e tests to be used with multipass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Defend Workflows “EDR Workflows” sub-team of Security Solution v8.8.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants