Skip to content

@W-18685522 Password Reset and Passwordless Integration Test#2669

Merged
jeremy-jung1 merged 53 commits intodevelopfrom
W-18685522-reset-and-passwordless-integration-test
Jul 8, 2025
Merged

@W-18685522 Password Reset and Passwordless Integration Test#2669
jeremy-jung1 merged 53 commits intodevelopfrom
W-18685522-reset-and-passwordless-integration-test

Conversation

@jeremy-jung1
Copy link
Collaborator

@jeremy-jung1 jeremy-jung1 commented Jun 27, 2025

Description

Work Item

Currently, there are no active e2e tests in the PWA Kit for Password Reset and Passwordless Login. This is because these flows are more complex and require user interaction for successful completion. Although not end to end due to the limitation of not being able to programmatically access an email inbox without some commitments (https://salesforce.quip.com/7Ab4AT4aeKyj), we will test to ensure that at least the PWA kit features are communicating necessary information to external services (e.g. SLAS and marketing cloud) and showing the right views.

Some features in the template retail react app is defaulted to be "off" (e.g., if they are dependent on SLAS private client). Thus, these features are not reflected in the current E2E test sites. For these "extra" features, a separate E2E test site is nightly synced with the branch extra-features-e2e-branch, which will also merge develop into itself nightly. E2E tests on these features will run against this site.

Types of Changes

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Documentation update
  • Breaking change (could cause existing functionality to not work as expected)
  • Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

  • Removing a public function or component or prop
  • Adding a required argument to a function
  • Changing the data type of a function parameter or return value
  • Adding a new peer dependency to package.json

Changes

  • (change1) Added playwright test for passwordless login API call
  • (change2) Added playwright test for password reset initiation API call and the actual reset API call
  • (change3) Added tests for email sending in ssr.js
  • (change4) A nightly job to sync the extra features e2e branch with the extra features e2e test site

How to Test-Drive This PR

  • (step1) Do npm run test:e2e:ui. Check that login.spec.js tests pass for desktop and mobile

Checklists

General

  • Changes are covered by test cases
  • CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

  • There are no changes to UI

or...

Localization

  • Changes include a UI text update in the Retail React App (which requires translation)

@jeremy-jung1 jeremy-jung1 requested a review from a team as a code owner June 27, 2025 06:47
@cc-prodsec
Copy link
Collaborator

cc-prodsec commented Jun 27, 2025

🎉 Snyk checks have passed. No issues have been found so far.

security/snyk check is complete. No issues have been found. (View Details)

license/snyk check is complete. No issues have been found. (View Details)

@jeremy-jung1 jeremy-jung1 changed the title @W-18685522 Reset and Passwordless Integration Test @W-18685522 Password Reset and Passwordless Integration Test Jun 27, 2025
e2e/config.js Outdated
PWA_E2E_USER_EMAIL: process.env.PWA_E2E_USER_EMAIL,
PWA_E2E_USER_PASSWORD: process.env.PWA_E2E_USER_PASSWORD,
SOCIAL_LOGIN_RETAIL_APP_HOME: "https://wasatch-mrt-feature-public.mrt-storefront-staging.com"
MORE_LOGIN_OPTIONS_RETAIL_APP_HOME: "https://wasatch-mrt-feature-private.mrt-storefront-staging.com"
Copy link
Collaborator

@hajinsuha1 hajinsuha1 Jun 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would we want to use an environment deployed in a pwa kit owned environment to make sure it doesnt get lost or deleted? I see in CI it uses this one:

run: export RETAIL_APP_HOME=https://scaffold-pwa-e2e-pwa-kit-private.mobify-storefront.com/

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also would we consider using a more generic name for the constant like RETAIL_REACT_APP_HOME_PRIVATE_CLIENT so it can be used for other private client E2E tests in the future?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RETAIL_APP_HOME doesn't have social and passwordless enabled, so consolidating on one site will lose us an E2E test "branch" of the PWA kit site configured without the social and passwordless changes, which has an impact on the UI. Right now we have two sites: one with the additional login features and one not, and I thought that was a good variety of sites.

I can make the deployment on the pwa-kit environment instead to make it more visible

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh sorry I meant, it looks like there are 2 PWA Kit sites:

Was wondering if we should reuse https://scaffold-pwa-e2e-pwa-kit-private.mobify-storefront.com instead of creating a new one in the PWA Kit project

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to keep the tests for the old login paths then we should create a new site. https://scaffold-pwa-e2e-pwa-kit-private.mobify-storefront.com/ is the one that the e2e tests get executed on. The current e2e tests for shopper login assumes the UI for these new login features are turned off.

The new tests in this PR work on a UI where the passwordless login is enabled, so it has to go on a separate site. If we reuse a site, then we will lose the e2e test "coverage" on the old configuration without the features enabled.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I think Jinsu is suggesting using the scaffold-pwa project because that is internal use only - so external non-PWA folks cannot alter or delete the environments

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the environment to be in scaffold-pwa and change the variable name to include other features that are defaulted to be off.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeremy-jung1 I know you already created the env, but is there potentially a better name that describes the configuration of the env?

I had originally thought the difference with this env vs the original e2e env is that it’s configured with a SLAS private client

Copy link
Collaborator Author

@jeremy-jung1 jeremy-jung1 Jul 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new environment is called EXTRA_FEATURES_E2E_RETAIL_APP_HOME. Instead of just features that has to be configured with SLAS Private Client, I thought a more encompassing name for features that are off by default would be good. Some features in the future might be dependent on other conditions. Social login is default to disabled too, but that isn't dependent on SLAS Private Client.

@jeremy-jung1 jeremy-jung1 deployed to more-logins-e2e July 1, 2025 16:28 — with GitHub Actions Active
- Gracefully handle missing SDK Clients in CommerceApiProvider [#2539](https://github.com/SalesforceCommerceCloud/pwa-kit/pull/2539)
- Refactor commerce-sdk-react to allow injecting ApiClients [#2519](https://github.com/SalesforceCommerceCloud/pwa-kit/pull/2519)


Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason the changelog_check required me to make an update to the commerce-sdk-react CHANGELOG, even though I don't have any changes here. Just putting a new line


expect(params.get('user_id')).toBe(config.PWA_E2E_USER_EMAIL)
expect(params.get('mode')).toBe('callback')
expect(params.get('channel_id')).toBe('RefArchGlobal')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move the siteID to config as well. Incase we need to move the site we're pointing to.


expect(params.get('user_id')).toBe(config.PWA_E2E_USER_EMAIL)
expect(params.get('mode')).toBe('callback')
expect(params.get('channel_id')).toBe('RefArch')
Copy link
Contributor

@shethj shethj Jul 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same. Avoid hardcoded config values.

@shethj
Copy link
Contributor

shethj commented Jul 3, 2025

Re-iterating for visibility:

Just curious about test orchestration.
So I see the new workflow you created deploys the code only for Node 22
However, the test runs for login.spec.js aren't really extracted into a separate playwright project . These tests will run with the other e2e tests.
And the main test workflow runs against a node matrix for Node 18, 20 and 22 x NPM 8, 9, 10, 11 x 3 setups
So what I suspect will happen is,
The social/passwordless login tests will run like 40 times like the other tests but since we're not deploying to the extra features instance.
All 40 runs will happen against the same Node 22 deployment which seems wasteful.

Consider extracting these tests into their own playwright project (add a new entry to the projects: [] where only these files run)
Create a new script in package.json for test:e2e:extra_features
In the main e2e.yml create a new job to run just these without the Node matrix.

@jeremy-jung1
Copy link
Collaborator Author

Screenshot 2025-07-06 at 8 55 19 PM ^ See that the extra features tests are not run in the regular project. The tests are failing because the current e2e tests are failing due to a recent merge. Screenshot 2025-07-06 at 8 55 41 PM ^ See that the extra features tests are run in the new project

shethj
shethj previously approved these changes Jul 8, 2025
Copy link
Contributor

@shethj shethj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding these in. LGTM 🚀

@jeremy-jung1 jeremy-jung1 merged commit e1306dc into develop Jul 8, 2025
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants