Add data-cy-* for items under /settings/appearance

[DeepSpaceHarbor]

Summary
Some of the components don't have unique attributes. Without them, the e2e tests will end up with weird selectors and code that's hard to understand.

This will add data-cy-* attributes to the elements shown under /settings/appearance

fyi: We already did this with login (#106).
The plan is to the the same with the rest of the app, one pr at a time.

Change log:

• Added data-cy for elements under settings/appearance
• Added data-cy-* for notifications.
• Changed the radio component. Added cypress tag to the fake radio button.
• Changed the toggle component. Added cypress tag to the fake toggle instead of the input element.

[mmso]

Changed the radio component. Added cypress tag to the fake radio button.
Changed the toggle component. Added cypress tag to the fake toggle instead of the input element.

I don't like the cypressTag prop that much because I think it becomes too involved in the component. I am fine to add data-cypress-whatever as an attribute that's passed onto the element.

As an alternative because it doesn't work for the cases where the component has a different style for the inputs (since cypress can't click on 0-height elements?), I think selecting it through cypress with label[for=${id}] would be ok even if it's said to be used sparingly on https://docs.cypress.io/guides/references/best-practices.html#Selecting-Elements because in here it's not connected to a specific CSS class or JS listener so it does not have a reason to change.

[dhoko]

if we always use data-cy we can pass cypressTag="appearance:sticky-labels"

[dhoko]

I don't like the cypressTag prop that much

Idem, but we need to find a way to tag the component a prop is a solution, maybe the name is too much "cypress" 😁

think selecting it through cypress with label[for=${id}]

It's better to use something not linked to the app itself/style etc. Having a data attribute is the best solution as we won't remove it by mistake because of what it means. We can't forget about it.

using id/classNames will create an issue one day, it always. That's why people always try to scope classNames when using JS or CSS.

[DeepSpaceHarbor]

Yeah, cypressTag is a bit weird. I'm open to suggestions for better name(s).

[mmso]

For me the issue is Cypress. Why can it not press inputs with 0 height? The browser can, so it should be able too.

[DeepSpaceHarbor]

Because, you want to interact with the same elements as the real user.
The real user wont be able to click that 0 height element, it makes sense for the test to avoid that as well.

[mmso]

The user is also interacting with the real input. Otherwise a change would never be triggered. In this case the label just defers the click to the input. So it does not matter if it happens on the input or on the label.

[mmso]

Why do you not always use data-cy? For this special case, I would be ok to destructure data-cy and put that on the label.

[DeepSpaceHarbor]

Closing. The focus has shifted to manual testing.
Will review again if needed when we start test automation.

[mmso]

Ok that's unfortunate. I feel like we were on the right track here. I will re-open this and take it over when I have more time.