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

[Security Solution] Document best practices for writing Cypress tests #153662

Open
Tracked by #153633
banderror opened this issue Mar 24, 2023 · 5 comments
Open
Tracked by #153633

[Security Solution] Document best practices for writing Cypress tests #153662

banderror opened this issue Mar 24, 2023 · 5 comments
Labels
documentation Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. technical debt Improvement of the software architecture and operational architecture test_ui_functional test

Comments

@banderror
Copy link
Contributor

banderror commented Mar 24, 2023

Epic: #153633

Summary

Write developer docs on the subject. Put them in https://github.com/elastic/security-team/tree/main/docs.

When writing the docs, let's think about and address the following concerns:

  • Stability, minimizing flakiness.
  • Resiliency to changes in the code, minimizing false negatives.
  • Speed.
  • Maintainability.
  • Readability and clarity.

Notes

Some best practices are already documented in kibana/x-pack/plugins/security_solution/cypress/README.md. We'll need to either add more practices to this doc or extract them into a separate document. The latter could live under security_solution/docs/testing or something like that, or be moved to https://github.com/elastic/security-team/tree/main/docs if it will contain any internal information.

I believe we'll need to come up with both general best practices (e.g. can be "cleanup should be done in before/beforeEach instead of after/afterEach blocks") and domain-specific best practices (e.g. can be "fleet packages should be installed only in a very limited number of tests"). We could share the general ones across AET in a common document, and keep the domain-specific practices in separate documents.

@banderror banderror added test test_ui_functional technical debt Improvement of the software architecture and operational architecture Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. documentation Team:Detection Rule Management Security Detection Rule Management Team 8.8 candidate labels Mar 24, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@MadameSheema
Copy link
Member

MadameSheema commented Mar 24, 2023

We already have things written in: kibana/x-pack/plugins/security_solution/cypress/README.md

@MadameSheema
Copy link
Member

Is this something just for Detections team?

@banderror
Copy link
Contributor Author

We already have things written in: kibana/x-pack/plugins/security_solution/cypress/README.md

Oh, I forgot about that @MadameSheema! It's nice that we have some recommendations there, but I think we'll need some more.

Is this something just for Detections team?

I believe we'll need to come up with both general best practices (e.g. can be "cleanup should be done in before/beforeEach instead of after/afterEach blocks") and domain-specific best practices (e.g. can be "fleet packages should be installed only in a very limited number of E2E tests").

The domain-specific ones will relate to only the Detection Engine, so Threat Hunting folks might want to come up with their own practices related to Timelines, Explore pages, or setting up source events before testing.

We can share the general ones across AET, and keep the domain-specific practices in separate documents.

These are great comments @MadameSheema, thank you for them. I'll add more info to the tickets based on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. technical debt Improvement of the software architecture and operational architecture test_ui_functional test
Projects
None yet
Development

No branches or pull requests

4 participants