Add store list & reviews test #2460
Conversation
WalkthroughThe changes in this pull request involve significant updates to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (5)
tests/pw/tests/e2e/singleStore.spec.ts (1)
25-27: Consider adding assertions to verify time format.While the test structure is good, it would be valuable to ensure the open-close times are displayed in the expected format.
Consider enhancing the test to verify the time format:
test('customer can view store open-close time on single store', { tag: ['@lite', '@customer'] }, async () => { - await customer.storeOpenCloseTime(data.predefined.vendorStores.vendor1); + const timeFormat = await customer.storeOpenCloseTime(data.predefined.vendorStores.vendor1); + // Add assertions to verify the time format matches expected pattern (e.g., HH:mm) });tests/pw/tests/e2e/storeReviews.spec.ts (1)
Line range hint
1-107: Consider test organization improvements.The test suite has a good structure but could benefit from some organizational improvements:
- Module state tests (enable/disable) could be grouped in their own describe block
- Consider adding test dependencies using test.describe.serial() for tests that must run in order
Example structure:
test.describe('Store Reviews test', () => { // ... setup code ... test.describe.serial('Module State Management', () => { test('admin can enable store reviews module', ...); // ... other module state tests ... test('admin can disable store reviews module', ...); }); test.describe('Admin Features', () => { // ... admin tests ... }); test.describe('Customer Features', () => { // ... customer tests ... }); test.describe('Vendor Features', () => { // ... vendor tests ... }); });tests/pw/pages/storeListingPage.ts (1)
140-152: LGTM! Consider enhancing the validation coverage.The added validation logic effectively verifies filter results for 'featured' and 'open-now' cases.
Consider these improvements:
- Add validation for other filter types ('by-location', 'by-category', 'by-ratings').
- Add descriptive error messages to the assertions. Example:
-await this.toHaveEqualCount(storeList.storeCard.storeCardDiv, storeList.storeCard.featuredLabel); +await this.toHaveEqualCount( + storeList.storeCard.storeCardDiv, + storeList.storeCard.featuredLabel, + 'Number of store cards should match number of featured labels' +);
- Add a comment explaining the validation purpose:
+// Validate that the filtered results match the expected criteria switch (filterBy) {tests/pw/pages/storeReviewsPage.ts (1)
21-27: Consider adding error handling for navigation failuresThe
enableStoreReviewsModulemethod should handle potential navigation failures and selector timeouts.async enableStoreReviewsModule(storeName: string) { + try { await this.goto(data.subUrls.backend.dokan.dokan); await this.toBeVisible(dokanAdmin.menus.storeReviews); await this.goIfNotThere(data.subUrls.frontend.vendorDetails(helpers.slugify(storeName)), 'networkidle'); await this.toBeVisible(selector.customer.cSingleStore.storeTabs.reviews); + } catch (error) { + throw new Error(`Failed to enable store reviews module: ${error.message}`); + } }tests/pw/pages/basePage.ts (1)
1601-1608: Add JSDoc documentation for better IDE support.The implementation looks good! The method efficiently uses Promise.all for parallel execution and follows the class's assertion method patterns. Consider adding JSDoc documentation for better IDE support and type safety:
+ /** + * Asserts that two elements have the same count + * @param selector1 - First element selector + * @param selector2 - Second element selector + * @param options - Optional configuration { timeout?: number; intervals?: number[] } + */ async toHaveEqualCount(selector1: string, selector2: string, options?: { timeout?: number; intervals?: number[] }) { await this.toPass(async () => { const [selector1Count, selector2Count] = await Promise.all([await this.getElementCount(selector1), await this.getElementCount(selector2)]); expect(selector1Count).toBe(selector2Count); }, options); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (14)
tests/pw/feature-map/feature-map.yml(3 hunks)tests/pw/pages/basePage.ts(1 hunks)tests/pw/pages/selectors.ts(2 hunks)tests/pw/pages/storeListingPage.ts(1 hunks)tests/pw/pages/storeReviewsPage.ts(2 hunks)tests/pw/tests/api/modules.spec.ts(1 hunks)tests/pw/tests/e2e/modules.spec.ts(1 hunks)tests/pw/tests/e2e/singleStore.spec.ts(1 hunks)tests/pw/tests/e2e/storeReviews.spec.ts(3 hunks)tests/pw/tests/e2e/storelisting.spec.ts(1 hunks)tests/pw/utils/apiUtils.ts(1 hunks)tests/pw/utils/interfaces.ts(1 hunks)tests/pw/utils/payloads.ts(2 hunks)tests/pw/utils/testData.ts(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- tests/pw/utils/interfaces.ts
- tests/pw/utils/testData.ts
🔇 Additional comments (20)
tests/pw/tests/api/modules.spec.ts (2)
Line range hint 1-42: LGTM for the rest of the implementation!
The test suite is well-structured with:
- Clear test coverage documentation
- Proper setup and teardown
- Comprehensive test cases for all module operations
- Schema validation for responses
21-21: 🛠️ Refactor suggestion
Inconsistent parameter style with test cases
While the afterAll hook uses a direct string parameter randomModule, the test cases on lines 33 and 39 still use array syntax [randomModule]. This inconsistency could lead to confusion.
Let's verify the apiUtils.activateModules method signature:
Consider maintaining consistency by either:
- Using array syntax in afterAll:
-await apiUtils.activateModules(randomModule);
+await apiUtils.activateModules([randomModule]);OR
2. Update the test cases to use direct string parameter:
-{ data: { module: [randomModule] } }
+{ data: { module: randomModule } }tests/pw/tests/e2e/singleStore.spec.ts (1)
25-27: LGTM! Test structure follows established patterns.
The test case follows the consistent pattern used throughout the file and is properly tagged for categorization.
Let's verify the implementation of the storeOpenCloseTime method being called:
✅ Verification successful
Implementation verified - test checks store hours visibility comprehensively
The storeOpenCloseTime method in SingleStorePage class has a thorough implementation that:
- Navigates to the specific store
- Verifies the store hours dropdown is interactive (hover)
- Validates visibility of time information container and heading
- Ensures all 7 days of the week are displayed with their corresponding times
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the implementation of storeOpenCloseTime method
# Expected: Find the method implementation in SingleStorePage class
# Search for the SingleStorePage class and storeOpenCloseTime method
ast-grep --pattern 'class SingleStorePage {
$$$
storeOpenCloseTime($_) {
$$$
}
$$$
}'
# Backup: Search using ripgrep if ast-grep doesn't find TypeScript files
rg -A 10 "storeOpenCloseTime.*\(" --type ts
Length of output: 1996
tests/pw/tests/e2e/modules.spec.ts (2)
Line range hint 1-53: Well-structured test suite with comprehensive coverage
The test suite is well-organized with:
- Clear test descriptions and proper tagging
- Good separation of concerns
- Appropriate setup and teardown
- Comprehensive coverage of module management features
44-44: Verify consistent usage of deactivateModules across test files
The change from array to single string parameter in deactivateModules looks correct, but we should ensure this new signature is used consistently across all test files.
Let's verify the usage pattern:
Additionally, consider adding a test case for deactivating multiple modules if that's a required feature, as the API change suggests we can only deactivate one module at a time now.
tests/pw/tests/e2e/storelisting.spec.ts (3)
Line range hint 1-67: LGTM! Well-structured test suite
The test suite is well-organized with:
- Clear test categories and appropriate tags
- Proper setup and teardown
- Focused test cases for each functionality
- Good progression from basic to advanced features
45-46: Verify the rating value change from '1' to '5'
The test now uses a rating value of '5' instead of '1'. Let's verify this change:
✅ Verification successful
Based on the search results, I can now generate the final response:
The rating value change from '1' to '5' is appropriate
The change from '1' to '5' star rating is valid because:
- The rating system uses a 1-5 scale, as evidenced by the test data generator:
rating: String(faker.number.int({ min: 1, max: 5 })) - Testing with the maximum rating value (5) is a better choice as it:
- Verifies the upper bound of the rating range
- Tests the most common positive user scenario (filtering for highly-rated stores)
- Aligns with the store review schema which validates ratings between 1-5
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the StoreListingPage implementation to understand valid rating values
# and verify if '5' is a more appropriate test value
# Search for rating-related constants or enums
rg -A 5 "rating" tests/pw/pages/storeListingPage.ts
# Search for the filterStores method implementation
ast-grep --pattern 'filterStores($_, $_) {
$$$
}'
Length of output: 643
Script:
#!/bin/bash
# Let's check the store list filters implementation to understand the rating values
rg -A 10 "rating\(" tests/pw/fixtures/storeList.ts
# Also check for any rating-related constants or configurations
rg -A 5 "rating" tests/pw/config/
Length of output: 214
Script:
#!/bin/bash
# Let's find the store list related files first
fd storeList
# Then search for rating-related code in all test files
rg -A 5 "rating" --type ts tests/
Length of output: 22149
53-53: Verify the open now filter implementation
The test for filtering open stores has been re-enabled. Let's verify the implementation:
✅ Verification successful
Open now filter implementation is properly verified
The implementation is correctly handling the open now filter:
- Clicks the open-now filter checkbox (
#open-now) - Applies the filter and waits for the store listing response
- Verifies that all displayed store cards have an open/close status indicator
- Validates that the number of store cards matches the number of open/close status indicators
The test ensures that only stores with open/close status are displayed when the filter is applied, which is the expected behavior for the open now filter.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the StoreListingPage implementation to understand
# how the open now filter is implemented
# Search for open-now related code
rg -A 5 "open-now" tests/pw/pages/storeListingPage.ts
# Search for the filterStores method implementation for open-now
ast-grep --pattern 'filterStores($filter) {
$$$
if ($filter === "open-now") {
$$$
}
$$$
}'
Length of output: 546
Script:
#!/bin/bash
# Let's check the implementation of the open-now filter in the store listing component
# and verify the store card status implementation
# Check for store listing component implementations
rg -A 10 "openNow|open-now" --type ts
# Check for store card status implementations
ast-grep --pattern 'class StoreCard {
$$$
status($$$) {
$$$
}
$$$
}'
# Check test implementation details
rg -A 10 "open now stores" tests/
Length of output: 5173
Script:
#!/bin/bash
# Let's check the store card implementation for open/close status
# and verify the actual filter validation
# Check for store card status implementation
rg -A 10 "openCloseStatus|storeCardDiv" tests/pw/pages/
# Check the actual filter validation in the test
rg -A 10 "toHaveEqualCount.*storeCard" tests/pw/pages/
Length of output: 6892
tests/pw/tests/e2e/storeReviews.spec.ts (1)
38-38: LGTM! Good practice to restore module state.
The afterAll hook ensures proper cleanup by reactivating the store reviews module after tests complete.
tests/pw/pages/storeReviewsPage.ts (3)
Line range hint 1-171: Overall implementation looks good!
The changes follow good testing practices and enhance the test coverage for store reviews functionality. The suggested improvements for error handling and verification will make the tests more robust.
9-11: Verify the selector path update impact
The selector path change from review to reviews might affect other test files using these selectors.
✅ Verification successful
Selector path change is safe to proceed
The change from review to reviews is localized to the storeReviewsPage.ts file and all occurrences have been properly updated. No other test files are using these selectors, making this a safe change that won't impact other parts of the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any usage of the old selector path
rg -l "selector\.customer\.cSingleStore\.review" tests/
Length of output: 92
Script:
#!/bin/bash
# Let's check the actual content to see if it's the old code being replaced
rg "selector\.customer\.cSingleStore\.review" tests/pw/pages/storeReviewsPage.ts -A 2 -B 2
Length of output: 547
Script:
#!/bin/bash
# Let's check if there are any other files using the customer store review selectors
rg "selector\.customer\.cSingleStore\.(review|reviews)" tests/ --type ts -A 2 -B 2
Length of output: 889
Line range hint 143-171: Verify test coverage for customer review methods
The customer review methods (reviewStore, viewOwnReview, cantReviewOwnStore) use the updated selector. Ensure test coverage for these methods.
✅ Verification successful
The previous search might have failed due to file extension matching. Let's try a broader search to find relevant test files and class usage patterns.
Let's check the actual test implementations to verify the coverage of these methods.
Test coverage verified for customer review methods
The methods have appropriate test coverage in tests/pw/tests/e2e/storeReviews.spec.ts:
reviewStore: Covered by "customer can edit store review" and "customer can create store review" testsviewOwnReview: Covered by "customer can view own review" testcantReviewOwnStore: Covered by "vendor can't review own store" test
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for test files covering these methods
rg -l "reviewStore|viewOwnReview|cantReviewOwnStore" tests/ --type spec
Length of output: 73
Script:
#!/bin/bash
# Let's try a broader search for test files related to store reviews
rg -l "storeReviews" tests/ --type-add 'spec:*.{spec,test}.*' --type spec
# Also search for the class name and its usage
rg -l "StoreReviewsPage" tests/
Length of output: 320
Script:
#!/bin/bash
# Let's examine the e2e test file content to verify coverage
rg "reviewStore|viewOwnReview|cantReviewOwnStore" -A 5 -B 2 tests/pw/tests/e2e/storeReviews.spec.ts
# Also check the test fixture setup
rg "StoreReviewsPage" -A 2 tests/pw/fixtures/page.ts
Length of output: 1763
tests/pw/feature-map/feature-map.yml (3)
289-289: Verify store open-close time UI implementation
The feature to display store open-close time on single store pages has been enabled.
Let's verify the related UI components and settings:
✅ Verification successful
The search results show comprehensive implementation of store open-close time functionality across the codebase, including dedicated templates (store-header-times.php, store-open-close.php), widget components (StoreOpenClose.php), settings pages, and vendor management. Let's verify the specific UI implementation for the single store view:
Store open-close time feature is properly implemented
The codebase has comprehensive implementation for store open-close time functionality:
- Dedicated template
store-header-times.phpwith proper time display formatting - Store time widget (
StoreOpenClose.php) with configuration options - Complete settings infrastructure for vendors to set their store hours
- Proper integration with both lite and pro versions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for store open-close time related components and settings
# Check for store time related templates/components
rg -l "store.*open.*close|store.*time" --type html --type php
# Check for store time related settings/configurations
rg -l "store_open_close|store_time" --type php
Length of output: 1763
Script:
#!/bin/bash
# Check the single store template implementation
rg -A 5 "store.*time" templates/store-header-times.php
# Verify widget integration
rg -A 5 "store.*time" includes/Widgets/StoreOpenClose.php
# Check store time settings
rg -A 5 "store.*time" includes/Vendor/SettingsApi/Settings/Pages/Store.php
Length of output: 5946
1301-1302: Verify store reviews module activation handling
Admin controls for enabling/disabling the store reviews module have been added. This requires proper implementation of:
- Module activation/deactivation hooks
- Graceful handling of existing reviews when module is disabled
- UI updates based on module status
Let's verify the implementation:
311-313: Verify store filtering implementation
Two new store filtering capabilities have been enabled:
- Filtering by store ratings
- Filtering for currently open stores
These features will enhance store discoverability, but require proper implementation of:
- Store ratings calculation and display
- Real-time store status checking
Let's verify the implementation:
✅ Verification successful
Based on the code analysis from the shell script outputs, I can now provide a final response:
Store filtering implementation is properly in place
The codebase shows comprehensive implementation of both store rating and open/close status filtering:
- Store Rating Filter:
- Rating data is available via
store_ratingproperty in store objects - Rating display and filtering logic exists in multiple templates
- Rating values are properly stored and retrieved from store metadata
- Store Open/Close Filter:
- Store hours functionality is fully implemented via
dokan_store_timesettings - Open/close status is tracked via
dokan_store_time_enabledflag - Real-time status checking exists through
dokan_is_store_open()function - Store hours are properly formatted and displayed in templates
The implementation includes:
- Frontend filter UI components
- Backend data storage and retrieval
- Filter state management
- Real-time status calculations
- Proper template integration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for store filtering implementation
# Check for store rating filter implementation
rg -l "store.*rating.*filter|filter.*store.*rating" --type php --type js
# Check for store open status filter implementation
rg -l "store.*open.*filter|filter.*store.*open" --type php --type js
# Check for store filter UI components
rg -l "store-filter|filter-store" --type html --type php
Length of output: 399
Script:
#!/bin/bash
# Let's examine the actual implementation details
# Check store rating filter implementation in dokan.js
rg "store.*rating.*filter|filter.*store.*rating" assets/js/dokan.js -C 5
# Check store open filter implementation in dokan.js
rg "store.*open.*filter|filter.*store.*open" assets/js/dokan.js -C 5
# Check store filter related functions in functions.php
rg "store.*open.*filter|filter.*store.*open" includes/functions.php -C 5
# Check store filter REST API implementation
rg "store.*open.*filter|filter.*store.*open" includes/REST/Manager.php -C 5
# Look for store filter components in Vue files
fd -e vue -x rg "store.*filter|filter.*store" {}
Length of output: 133599
Script:
#!/bin/bash
# Let's check for store filter implementations in Vue components and templates
# Look for store filter components in Vue files
fd -e vue -x rg -A 5 -B 5 "store.*filter|filter.*store" {}
# Check for store filter templates
fd -e php -g "*template*.php" -x rg -A 5 -B 5 "store.*filter|filter.*store" {}
# Check for store filter JavaScript implementations
rg -A 5 -B 5 "store.*rating.*filter|filter.*store.*rating|store.*open.*filter|filter.*store.*open" assets/js/vue-*.js
Length of output: 136065
Script:
#!/bin/bash
# Let's check the store filter implementations in Vue components
# Look for store filter components in Vue files
fd -e vue -x rg -A 5 -B 5 "store.*filter|filter.*store|store.*rating|store.*open" {}
# Check for store filter templates in PHP files
fd -e php -g "*store*.php" -x rg -A 5 -B 5 "store.*filter|filter.*store|store.*rating|store.*open" {}
# Check for store filter JavaScript implementations in store-related files
fd -e js -g "*store*.js" -x rg -A 5 -B 5 "store.*filter|filter.*store|store.*rating|store.*open" {}
Length of output: 40972
tests/pw/utils/apiUtils.ts (2)
867-870: LGTM! Clean implementation of flexible parameter type.
The change to accept both string and string array for moduleIds improves API usability while maintaining backward compatibility.
876-879: LGTM! Consistent implementation with activateModules.
The changes mirror the activateModules implementation, maintaining consistency across the API.
tests/pw/utils/payloads.ts (2)
3602-3606: Verify impact of changing module property from array to string.
The module property type has been changed from array to string for the 'booking' module in both activation and deactivation payloads. This change could affect existing code that expects an array.
Let's verify the usage of these payloads across the codebase:
✅ Verification successful
Based on the search results, I can now provide a final response:
The module property change is safe - API already handles both string and array inputs
The codebase shows that the API utility methods activateModules and deactivateModules in tests/pw/utils/apiUtils.ts already handle both string and array inputs by converting single strings to arrays:
async activateModules(moduleIds: string | string[], auth?: auth) {
if (!Array.isArray(moduleIds)) {
moduleIds = [moduleIds];
}
const [response, responseBody] = await this.put(endPoints.activateModule, { data: { module: moduleIds }, headers: auth });
...
}The change in the payload is consistent with this implementation, as the API will properly handle the string input by converting it to an array before making the request.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential impacts of changing module property type
# Search for usages of deactivateModule and activateModule
rg -A 5 "deactivateModule|activateModule"
# Search for any array operations on module property
ast-grep --pattern 'module[$_].*([$_])'
Length of output: 7375
Line range hint 3561-3597: LGTM! Module IDs follow consistent naming conventions.
The new module IDs have been added with consistent naming patterns and the colorSchemeCustomize property has been correctly renamed to colorSchemeCustomizer.
Let's verify the module IDs are used consistently across the codebase:
✅ Verification successful
Based on the search results, I can now generate the final response:
Module IDs are used consistently across the codebase
The new module IDs and the renamed colorSchemeCustomizer property are used consistently throughout the codebase:
colorSchemeCustomizeris used consistently in test files and changelog- New module IDs like
auction,mangopay,orderMinMax,printful,productAdvertising,productSubscription,rankMath, andrequestForQuotationare used consistently in test files, interfaces, payloads, and feature maps - The naming conventions (lowercase with underscores) are maintained across all usages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent usage of module IDs across the codebase
# Search for any inconsistent usage of colorSchemeCustomize vs colorSchemeCustomizer
rg -i "colorSchemeCustomize"
# Search for usage of new module IDs to ensure consistency
rg -i "auction|mangopay|orderMinMax|printful|productAdvertising|productSubscription|rankMath|requestForQuotation"
Length of output: 103744
tests/pw/pages/selectors.ts (1)
803-804: LGTM! The selectors for store reviews section are well-defined.
The new selectors follow the existing code style and naming conventions. The selectors are specific and descriptive:
storeReviewsDivtargets the main containerstoreReviewsTexttargets the heading text
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
tests/pw/pages/storeReviewsPage.ts (1)
38-38: Fix comment typoThe comment "reviews is visible" should be "no reviews is visible" to match the actual verification being performed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
tests/pw/pages/storeReviewsPage.ts(2 hunks)
🔇 Additional comments (4)
tests/pw/pages/storeReviewsPage.ts (4)
29-41: Add verification for module settings persistence
The method should verify that the module remains disabled after page refresh.
async disableStoreReviewsModule(storeName: string) {
await this.goto(data.subUrls.backend.dokan.dokan, { waitUntil: 'domcontentloaded' }, true);
await this.notToBeVisible(dokanAdmin.menus.storeReviews);
// no reviews table is visible
await this.goIfNotThere(data.subUrls.backend.dokan.storeReviews);
await this.notToBeVisible(dokanAdmin.storeReviews.storeReviewsDiv);
// no reviews is visible
await this.goIfNotThere(data.subUrls.frontend.storeReviews(helpers.slugify(storeName)));
await this.toBeVisible(selector.customer.cSingleStore.reviews.noReviewsFound);
+
+ // verify settings persistence after refresh
+ await this.page.reload();
+ await this.notToBeVisible(dokanAdmin.menus.storeReviews);
}20-41: Well-structured integration with existing code
The new methods are well-integrated with the existing codebase:
- Follow the page object model pattern
- Maintain consistent error handling
- Use proper wait strategies
- Verify both admin and frontend states
11-11: Verify selector update across the codebase
The selector path has been updated from selector.customer.cSingleStore.review to selector.customer.cSingleStore.reviews. While this change is reflected in this file, we should verify its usage across the codebase.
✅ Verification successful
Selector update is consistent across the codebase
The verification shows that there are no instances of the old selector pattern (selector.customer.cSingleStore.review) in the codebase, and the new pattern (selector.customer.cSingleStore.reviews) is used consistently in storeReviewsPage.ts. The change appears to be properly implemented.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining usage of the old selector pattern
rg "selector\.customer\.cSingleStore\.review[^s]" --type ts
# Search for the new selector pattern to ensure consistent usage
rg "selector\.customer\.cSingleStore\.reviews" --type ts
Length of output: 346
20-27: 🛠️ Refactor suggestion
Add verification for module settings persistence
The method should verify that the module remains enabled after page refresh to ensure settings persistence.
async enableStoreReviewsModule(storeName: string) {
await this.goto(data.subUrls.backend.dokan.dokan);
await this.toBeVisible(dokanAdmin.menus.storeReviews);
await this.goIfNotThere(data.subUrls.frontend.vendorDetails(helpers.slugify(storeName)), 'networkidle');
await this.toBeVisible(selector.customer.cSingleStore.storeTabs.reviews);
+
+ // verify settings persistence after refresh
+ await this.page.reload();
+ await this.toBeVisible(dokanAdmin.menus.storeReviews);
}Likely invalid or redundant comment.
* chore: bump version to 3.14.0 * Add geolocation map tests * Update feature map * fix coverage map * Auction tests (getdokan#2452) * Add a test * Update feature map * Fix lint issue * change filename temporary * Revert filename to original * Fix notice test * Fix commission test * Add new tests to featuremap (getdokan#2453) * Add new tests to feature map * Add new tests to featuremap * Skip shipstation tests * Add notice for version compatibility. (getdokan#2450) * Add notice for version compatibility. * Added dokan pro update message. * Added dokan pro update message. * Added dokan pro update message. * fix: plugin version after activation (getdokan#2447) * chore: bump version to 3.14.0 * chore: Released Version 3.14.0 * Fix commission upgrader (getdokan#2463) * Fix commission upgrader * Add database backup message in upgrade. * chore: Released Version 3.14.1 * Fix skipped product tests (getdokan#2457) * Fix and update skipped product tests * Update a variable * Add store list & reviews test (getdokan#2460) * Fix skipped store tests * Add store reviews tests * Update comment * skipped a test * Enhancement: product commission bulk edit (getdokan#2464) * Remove $commission_type variable it was not used * Save fixed as default commission type * Save bulk product commission. * Update bulk edit ui Skip reverse withdrawal and advertisement product id * Update bulk edit ui Skip reverse withdrawal and advertisement product id * Revert alignment * chore: bump version to v3.14.2 * Add Commission tests (getdokan#2471) * add new commission tests * Add commission tests * Add vendor coupon tests (getdokan#2470) * Add vendor coupon tests * Update test tags --------- Co-authored-by: Aunshon <[email protected]> Co-authored-by: Aunshon <[email protected]> Co-authored-by: KAMRUZZAMAN <[email protected]>
* chore: bump version to 3.14.0 * Add dokan tracking tests * Add commission meta box test * Update feature map * Update config file * Update feature map * Add vendor filters test * Add a shortcode test * Fix commission tests * Add geolocation tests * Auction tests (getdokan#2452) * Add a test * Update feature map * Fix lint issue * change filename temporary * Revert filename to original * Fix notice test * Fix commission test * Add new tests to featuremap (getdokan#2453) * Add new tests to feature map * Add new tests to featuremap * Skip shipstation tests * Add notice for version compatibility. (getdokan#2450) * Add notice for version compatibility. * Added dokan pro update message. * Added dokan pro update message. * Added dokan pro update message. * fix: plugin version after activation (getdokan#2447) * chore: bump version to 3.14.0 * chore: Released Version 3.14.0 * Fix commission upgrader (getdokan#2463) * Fix commission upgrader * Add database backup message in upgrade. * chore: Released Version 3.14.1 * Fix skipped product tests (getdokan#2457) * Fix and update skipped product tests * Update a variable * Add store list & reviews test (getdokan#2460) * Fix skipped store tests * Add store reviews tests * Update comment * skipped a test * Enhancement: product commission bulk edit (getdokan#2464) * Remove $commission_type variable it was not used * Save fixed as default commission type * Save bulk product commission. * Update bulk edit ui Skip reverse withdrawal and advertisement product id * Update bulk edit ui Skip reverse withdrawal and advertisement product id * Revert alignment * chore: bump version to v3.14.2 * Add Commission tests (getdokan#2471) * add new commission tests * Add commission tests * Add vendor coupon tests (getdokan#2470) * Add vendor coupon tests * Update test tags --------- Co-authored-by: Aunshon <[email protected]> Co-authored-by: Aunshon <[email protected]> Co-authored-by: KAMRUZZAMAN <[email protected]>
* Add booking product details test * Add booking product tests * Fix mix-max flaky issue * Update product name & id reference * update tags test * chore: bump version to 3.14.0 * Fix failed tests * Fix flaky tests * Fix commission tests * Update commission test logic * Add new tests & update feature map * Auction tests (getdokan#2452) * Add a test * Update feature map * Fix lint issue * change filename temporary * Revert filename to original * Fix notice test * Fix commission test * Add new tests to featuremap (getdokan#2453) * Add new tests to feature map * Add new tests to featuremap * Skip shipstation tests * Add notice for version compatibility. (getdokan#2450) * Add notice for version compatibility. * Added dokan pro update message. * Added dokan pro update message. * Added dokan pro update message. * fix: plugin version after activation (getdokan#2447) * chore: bump version to 3.14.0 * chore: Released Version 3.14.0 * Fix commission upgrader (getdokan#2463) * Fix commission upgrader * Add database backup message in upgrade. * chore: Released Version 3.14.1 * Fix skipped product tests (getdokan#2457) * Fix and update skipped product tests * Update a variable * Add store list & reviews test (getdokan#2460) * Fix skipped store tests * Add store reviews tests * Update comment * skipped a test * Enhancement: product commission bulk edit (getdokan#2464) * Remove $commission_type variable it was not used * Save fixed as default commission type * Save bulk product commission. * Update bulk edit ui Skip reverse withdrawal and advertisement product id * Update bulk edit ui Skip reverse withdrawal and advertisement product id * Revert alignment * chore: bump version to v3.14.2 * Add changes * Add Commission tests (getdokan#2471) * add new commission tests * Add commission tests * Add vendor coupon tests (getdokan#2470) * Add vendor coupon tests * Update test tags --------- Co-authored-by: Aunshon <[email protected]> Co-authored-by: Aunshon <[email protected]> Co-authored-by: KAMRUZZAMAN <[email protected]>
All Submissions:
Changes proposed in this Pull Request:
Related Pull Request(s)
Closes
How to test the changes in this Pull Request:
Changelog entry
Title
Detailed Description of the pull request. What was previous behaviour
and what will be changed in this PR.
Before Changes
Describe the issue before changes with screenshots(s).
After Changes
Describe the issue after changes with screenshot(s).
Feature Video (optional)
Link of detailed video if this PR is for a feature.
PR Self Review Checklist:
FOR PR REVIEWER ONLY:
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Tests
Chores