e2e Tests: Publish test helpers as a reusable library

[nwmac]

We currently have a bunch of Page Objects in cypress/integration/po and we have other code in the support and plugins folders.

This code needs to be packaged in a way that QA or other groups can leverage to write their own e2e tests - leveraging what ww are doing here.

Simplest option would be to publish as an npm library (e.g. rancher/cypress) and restructure as necessary to support reuse. It would be good if the dashboard e2e tests could reference this library directly in the repository to simplify the e2e test creation process for dashboard - i.e. avoid having to publish a new version of the library in the case that writing a test requires a new Page Object or utlity.

This also needs documenting.

[cnotv]

Hey @nwmac sounds good to do that. I would start by writing down first most of the tests cases we may have around, then try to polish the logic behind the PO, including the way we identify elements.

We may also include the use of other libraries as well, e.g. @testing-library/cypress so we do not reinvent the wheel.

[cnotv]

@nwmac we have several topics which are still open to be discussed.

I mentioned already to @richard-cox that the PO as they are set are just slowing down and creating some problems, so maybe we should limit them, or replace some cases with actions, as well as not apply them everywhere for everything. For sure this needs to be discussed and it has been already mentioned more than once. All these points came out while we are working on unrelated issues for E2E which are slowing down as well the development.

It would be nice to collect thoughts through the company and other people working on the E2E, so we have something tangible to write down and not just unproven concept.

[cnotv]

Another big problem which may probably be needed to tackle down is related on where do we want to place our identifiers. We do not have a consistent way on how we pass attributes and we are not allowed to do directly to the component in most of the cases.

v-bind="$attrs"

It may force us to wrap in another element just for this reason, which we definitely do not want to have.

[cnotv]

@nwmac Given this list of unclear states, I would rather suggest to create the repository, create the library, setup the publishing process, documentation and tree structure. Successively we may extend commands/PO while we have a common ground.

This would speed up the process and avoid to discuss here about further issues.