[Security Solution] Document best practices for writing Cypress tests

[banderror]

Epic: https://github.com/elastic/kibana/issues/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.

[elasticmachine]

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

[elasticmachine]

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

[MadameSheema]

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

[MadameSheema]

Is this something just for Detections team?

[banderror]

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.