Transform component tests from Jest to Playwright CT

[bedrich-schindler]

This is blocked by: #588

---

Aim of this issue to transform component tests from Jest to Playwright CT according to PR #588. To point out basic principles designed in #588:

• Study concepts from Playwright component testing #588 first!
• Read Playwright Component Testing documentation first!
• Increase your PW_WORKERS (e.g. to 10) to increase development speed and use npm run test:playwright:all-with:update -- src/components/<component> to test components independently. Running all the tests during the development might be pretty slow.
• Tests must be placed in __tests__ directory and named <ComponentName>.spec.jsx (<ComponentName>.test.jsx is designated for Jest tests).
• Tested component must be wrapped and imported from its story named <ComponentName>.story.jsx. Stories sit in __tests__ directory as well. This means that component must not be imported directly into test (<ComponentName>.spec.jsx), but always through its story.
• Try to keep stories simple but at the same time, try to keep them consistent across tests. For example, keep tests for ref as same as possible. If you see possibility for abstraction, let's discuss it on simple example prior to implementation.
• Unless you find useful to do it differently, group tests by following names: visual (for props that can affect component visually), non-visual (for props that cannot affect component visually) and functionality (for functional tests)
• Even though Jest tests are already there, always review all the props. Especially, if there is space and it is not time exhausting, think about improving functional testing (e.g. test interaction with keyboard, disabled states and vice versa - see Alert and Button tests)
• For propTests that are possibly global, place them in globally scoped folder tests/playwright/propTests. If they are simple, do not hesitate to inline them. But I think it is better to create _propTests inside __tests__ directory and create propTest for each prop you need.
• Study tests/playwright/propTests and its content. For enumeration and boolean values, there are all possible values present. For optional arguments representing component (like beforeLabel, afterLabel, icon, ...) there is only one item per propTest. Why? Because it is optional so state when it is not present is probably covered in other tests. If there is same case when this is not true, test both options.
• If there are props that requires some configuration/state of browser, check tests/playwright/propTests/labelVisibilityPropTest.js where I modify browser width to test different viewports. You can accomplish that by creating onBeforeTest hook on propTest. Always try to cover all edge-cases as I did at labelVisibilityPropTest.js.
• Use mixPropTypes() to cover all visual combinations like color x variant x disabled state and so. Do not pass optional props into mixPropTypes() unless it is necessary. We want to have covered all visual states, but e.g. icon before and after label probably does not have to be tested in combination with color, disabled state and so. So think about it. We want good coverage, but not overwhelming coverage until necessary.
• The more complex component is, the more complex testing should be perform. So take you time when testing non-trivial components like Modal, SelectField, Popover and so. Think also about if different vieport can have impact on it.
• If you need some component to pass to your tested component, try to import component designed for tests, try to avoid importing other React UI components if it make sense (e.g. it make sense to use form fields and buttons inside of modal, but it is not necessary to pass badges before and after label). Why? Because if we change React UI component, it should impact whole library minimally, so it means that if we use Badge everywhere, its change would result in tousand changed snapshots. Thus is better to use components like tests/playwright/components/TestIcon.

Transformation should be done in separate issues and pull requests to prevent reworking huge pull request if we do not agree on some principle.