test(dark-light-modes): reusable test code

[max-umain]

Describe pull-request

This PR introduces reusable test code, that allows for easily generating tests for any component, based on their existing tests and dynamically modifying mode (lightmode, darkmode) and mode variant (primary, secondary).

In this PR I have also applied this dynamic test for almost all components, so now they have screenshot tests for modes and mode variants.

Issue Linking:

The following tickets are addressed in this PR

• Jira: CDEP-3638
• Jira: CDEP-3640
• Jira: CDEP-3641
• Jira: CDEP-3642
• Jira: CDEP-3643
• Jira: CDEP-3644
• Jira: CDEP-3645
• Jira: CDEP-3646
• Jira: CDEP-3647
• Jira: CDEP-3648
• Jira: CDEP-3649
• Jira: CDEP-3651
• Jira: CDEP-3652
• Jira: CDEP-3653
• Jira: CDEP-3654
• Jira: CDEP-3655
• Jira: CDEP-3657
• Jira: CDEP-3658
• Jira: CDEP-3659
• Jira: CDEP-3660
• Jira: CDEP-3661
• Jira: CDEP-3664 (I believe this is covered in the default tests for table)
• Jira: CDEP-3665
• Jira: CDEP-3666
• Jira: CDEP-3667
• Jira: CDEP-3668 (I believe this is covered in the filtering or column-filtering tests for table)
• Jira: CDEP-3669
• Jira: CDEP-3670
• Jira: CDEP-3673
• Jira: CDEP-3674
• Jira: CDEP-3675
• Jira: CDEP-3676
• Jira: CDEP-3677
• Jira: CDEP-3678
• Jira: CDEP-3679
• Jira: CDEP-3680
• Jira: CDEP-3681
• Jira: CDEP-3682

How to test

Provide detailed steps for testing, including any necessary setup.

1. Go to the root directory of tegel
2. Run npm run test

Checklist before submission

• I have added unit tests for my changes (if applicable)
• All existing tests pass
• I have updated the documentation (if applicable)
• Not breaking production behavior
• Behavior available in storybook with documented descriptions (if applicable)
• npm run build-all without errors

Suggested test steps

• Browser testing (Chrome, Safari, Firefox)
• Keyboard operability
• Interactive elements have labels.
• Storybook controls
• Design/controls/props is aligned with other components
• Dark/light mode and variants
• Input fields – values should be displayed properly
• Events

Screenshots

None

Additional context

How to use the reusable test code

In .e2e.ts test files, extract the tests within the test.describe.parallel that have a toHaveScreenshot and put them below one of the following

testConfigurations.withModeVariants.forEach((config) => {
  test.describe.parallel(getTestDescribeText(config, testDescription), () => {
    test.beforeEach(async ({ page }) => {
      await setupPage(page, config, componentTestPath, componentName);
    });

or

testConfigurations.basic.forEach((config) => {
  test.describe.parallel(getTestDescribeText(config, testDescription), () => {
    test.beforeEach(async ({ page }) => {
      await setupPage(page, config, componentTestPath, componentName);
    });

and make sure to close the functions with curly braces and parentheses. Also insert code from existing (if there is any) test.beforeEach to this one, and also removing the page.goto lines in every test in the file.

[github-actions]

Playwright test results

 789 passed
 1 skipped

Details

 790 tests across 134 suites
 2 minutes, 18 seconds
 c25c1a5

Skipped tests

src/components/table/table/test/expandable-row-autocollapse/expandable-row-autocollapse.e2e.ts › tds-table-expandable-row-autoCollapse › NEEDS FIXING: expanding one row collapses the others when autoCollapse is true

[aws-amplify-eu-north-1]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-934.d3fazya28914g3.amplifyapp.com

[nathalielindqvist]

Going through all of the new screenshots PRs that have been posted using this reusable code as a base, it seems like there are still residual tests in light mode (specifically primary light mode if the component has mode variants) that produce duplicates of screenshots. This has happened all throughout the PRs. Before moving forward with this idea I think it would be good to align on how we want to tackle this problem, if we want to remove the original tests entirely or if this script should be tweaked to not produce results in (primary) light mode. Or, if there is another way to go about this and still get the result of dark mode tests. Having a larger discussion within the dev group sounds like a good idea to me.

[theJohnnyMe]

Changes in PR are touching too large amount of files to provide detailed code review. However, idea of having configuration file and less lines of code to test both dark and light mode and its submodes looks good to me.

Looking in some components we could further optimize this by just taking screenshots using "beforeEach" trick done here and moving other logic outside - for example checking if disabled cursor is disabled. That would be a step in next improvement.

Overall great work!

[theJohnnyMe]

I have updated the title of PR, just a bit shorter.

[max-umain]

Changes in PR are touching too large amount of files to provide detailed code review. However, idea of having configuration file and less lines of code to test both dark and light mode and its submodes looks good to me.

I think the idea was that everything in this PR has been merged from other PRs that has been approved, so I don't think any of the files in this PR are necessary to review as they have already been approved, except for testConfiguration.ts

[ckrook]

Have went through every sub-pr before they where merge into this larger PR, and it looked good to me.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud