spartacus
spartacus copied to clipboard
feat: The 'Save cart for later' button in <cx-add-to-saved-cart> is hidden if its current cart has no entries
#Closes https://jira.tools.sap/browse/CXSPA-527
Test summary
Run details
Project | spartacus |
Status | Passed |
Commit | 7fc932516b ℹ️ |
Started | Sep 20, 2022 2:24 PM |
Ended | Sep 20, 2022 2:33 PM |
Duration | 08:54 💡 |
OS | Linux Ubuntu - 20.04 |
Browser | Electron 91 ![]() |
View run in Cypress Dashboard ➡️
Flakiness
![]() |
cypress/integration/ssr/pages.core-e2e-spec.ts ![]() |
3 ![]() |
|
---|---|---|---|
1 | SSR > should render homepage |
![]() |
|
2 | SSR > should render PLP |
![]() |
|
3 | SSR > should render PDP |
![]() |
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard
@Zeyber I have spent the last few days trying to add an E2E test for this feature. I will explain the abnormal difficulty.
I have implementing this test plan:
- Add a product to cart.
- Go to cart. Check that "Save cart for later" is enabled.
- Save the product for later. Check that "Save cart for later" is disabled.
When executing step 3, the code is trying to update the saved cart, which does not exist yet. Because of NgRX state management, this creates a malformed HTTP request causing the program to terminate early. I have not been able to reproduce it outside of Cypress.
I can continue pursuing this if it is absolutely necessary. A possible solution is to simply not allow the program to query for undefined saved carts.
Finally found the issue. When the application loads, it also loads the selective (saved) cart.
Because Cypress is so quick, it creates a race hazard where UI is loaded and interacted with, but the saved cart has not been loaded yet, thus causing issues. The solution is to use Angular's router to navigate through routes instead of using cy.visit
which triggers the application's loading code again.
@Zeyber I'm not sure what's missing from the set-up; if you can share the full URL of the request that is responded with 400, that may help. That request + error looks familiar.