Add Pro module tests(wholesale, vendorstaff) (test automation) #2379
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThe changes encompass a series of updates to the feature map configuration, vendor capabilities, and various page classes within the testing framework. Key modifications include enhancements to vendor functionalities, such as managing shipping methods and payment options, alongside the introduction of new methods and constants for better code organization. Additionally, several typos in comments have been corrected, and the structure of selectors has been improved for clarity and maintainability. Changes
Possibly related PRs
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: 10
Outside diff range and nitpick comments (23)
tests/pw/tests/e2e/vendorStaff.spec.ts (3)
48-72: LGTM! Consider adding more test cases.The new test suite 'Wholesale test (customer)' is well-structured with proper setup and teardown processes. The test case is appropriately tagged and checks an important functionality.
Consider adding more test cases to this suite to cover different scenarios, such as:
- Checking if the staff cannot access menus they don't have permission for.
- Verifying the behavior when updating staff permissions.
- Testing edge cases with empty or invalid permissions.
69-71: LGTM! Consider adding assertions for clarity.The test case 'VendorStaff can view allowed menus' is concise and focused on a single functionality.
Consider adding explicit assertions to make the test's expectations clearer. For example:
test('VendorStaff can view allowed menus', { tag: ['@pro', '@staff'] }, async () => { const visibleMenus = await staff.viewPermittedMenus(data.vendorStaff.basicMenuNames); expect(visibleMenus).toEqual(data.vendorStaff.basicMenuNames); });This assumes that
viewPermittedMenusreturns the list of visible menus. If it doesn't, you might need to adjust the method to return this information.
74-81: LGTM! Consider adding type annotations and adjusting the default value.The
createPayloadfunction is well-structured and uses modern JavaScript features effectively.Consider the following improvements:
- Add type annotations for better type safety:
function createPayload(capabilitiesArray: string[], access: boolean = true): { capabilities: Array<{ capability: string, access: boolean }> } { // ... function body ... }
- Consider changing the default value of
accesstofalse. This follows the principle of least privilege, where access is denied by default:function createPayload(capabilitiesArray: string[], access: boolean = false) { // ... function body ... }
- Add a brief JSDoc comment to explain the function's purpose and parameters:
/** * Creates a payload object for updating staff capabilities. * @param capabilitiesArray - An array of capability strings. * @param access - Whether to grant or deny access to the capabilities. Defaults to false. * @returns An object with a 'capabilities' property containing an array of capability objects. */ function createPayload(capabilitiesArray: string[], access: boolean = false): { capabilities: Array<{ capability: string, access: boolean }> } { // ... function body ... }tests/pw/pages/colorsPage.ts (1)
Line range hint
1-85: Consider refactoring theaddColorPalettemethod for improved maintainability.While the recent changes have improved code clarity, the
addColorPalettemethod is quite long and handles multiple responsibilities. Consider refactoring this method to improve readability and maintainability. Some suggestions:
- Extract the color palette setting logic into a separate method.
- Create a dedicated method for color assertions.
- Use a configuration object or enum for field names to reduce repetition.
Example refactoring:
private async setColorPalette(paletteChoice: string, paletteName: string, paletteValues: paletteValues) { if (paletteChoice === 'predefined') { await this.setPredefinedPalette(paletteName); } else { await this.setCustomPalette(paletteValues); } } private async assertColors(paletteValues: paletteValues) { // Move all color assertions here } async addColorPalette(paletteName: string, paletteValues: paletteValues, paletteChoice: string = 'predefined') { await this.goToDokanSettings(); await this.click(settingsAdmin.menus.colors); await this.setColorPalette(paletteChoice, paletteName, paletteValues); // save settings await this.saveSettings(); await this.goIfNotThere(data.subUrls.frontend.vDashboard.settingsStore); await this.assertColors(paletteValues); }This refactoring would make the code more modular and easier to maintain.
tests/pw/pages/vendorStaffPage.ts (1)
Potential Duplication Detected in VendorStaffPage Additions
The newly added methods
viewPermittedMenusandgoToVendorDashboard, as well as the selectorvendorDashboard, already exist in other parts of the codebase. This duplication could lead to maintainability challenges and inconsistencies.Affected Areas:
vendorStaff.spec.tsusesviewPermittedMenus.vendorPage.tscontains thegoToVendorDashboardmethod.- Multiple pages (
vendorDashboardPage.ts,settingPage.ts,reverseWithdrawsPage.ts,menuManagerPage.ts,vendorPage.ts,colorsPage.ts,customerPage.ts) utilize theselector.vendor.vDashboardselector.Analysis chain
Line range hint
1-132: Summary: Positive addition to VendorStaffPage class.The changes made to this file enhance the
VendorStaffPageclass by adding functionality to view permitted menus. The newviewPermittedMenusmethod aligns well with the class's purpose and follows the established coding patterns. The addition of thevendorDashboardconstant also improves code readability and maintainability.These changes contribute positively to the testing framework for the Pro module, specifically for vendor staff functionalities, which aligns with the PR objectives.
To ensure that these changes don't conflict with or duplicate existing functionality, please run the following verification:
This will help identify any potential overlaps or inconsistencies with other parts of the testing framework.
</run_scripts>
</run_scripts>
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for similar methods or usages in other test files # Search for similar method names or usages rg --type typescript -g '!vendorStaffPage.ts' 'viewPermittedMenus|goToVendorDashboard' # Check for other usages of vendorDashboard selector rg --type typescript -g '!vendorStaffPage.ts' 'selector\.vendor\.vDashboard'Length of output: 237
Script:
#!/bin/bash # Description: Check for similar methods or usages in other TypeScript test files # Search for similar method names or usages in .ts and .tsx files excluding vendorStaffPage.ts rg -t ts -t tsx -g '!vendorStaffPage.ts' 'viewPermittedMenus|goToVendorDashboard' # Check for other usages of vendorDashboard selector in .ts and .tsx files excluding vendorStaffPage.ts rg -t ts -t tsx -g '!vendorStaffPage.ts' 'selector\.vendor\.vDashboard'Length of output: 213
Script:
#!/bin/bash # Description: Check for similar methods or usages in other TypeScript test files using file extensions # Search for similar method names or usages in .ts and .tsx files excluding vendorStaffPage.ts rg -g '*.ts' -g '*.tsx' -g '!vendorStaffPage.ts' 'viewPermittedMenus|goToVendorDashboard' # Check for other usages of vendorDashboard selector in .ts and .tsx files excluding vendorStaffPage.ts rg -g '*.ts' -g '*.tsx' -g '!vendorStaffPage.ts' 'selector\.vendor\.vDashboard'Length of output: 1595
tests/pw/pages/menuManagerPage.ts (2)
15-19: LGTM: Good encapsulation of navigation logic.The
goToMenuManagerSettingsmethod effectively encapsulates the navigation logic, which can reduce code duplication throughout the class. It's consistent with the single responsibility principle and correctly uses async/await.Consider adding a brief JSDoc comment to describe the method's purpose and any side effects:
/** * Navigates to the Menu Manager Settings page. */ async goToMenuManagerSettings() { // ... existing code ... }
11-13: Consider removing the unnecessary constructor.The current constructor doesn't add any functionality beyond calling the superclass constructor. Removing it would slightly reduce code complexity without affecting the class's behavior.
You can safely remove the constructor:
- constructor(page: Page) { - super(page); - }This change will implicitly use the superclass constructor.
Tools
Biome
[error] 11-13: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
tests/pw/pages/reverseWithdrawsPage.ts (1)
164-165: LGTM: Consistent use of the newvendorDashboardconstant.The changes in the
vendorCantWithdrawandvendorStatusInactivemethods correctly utilize the newly introducedvendorDashboardconstant. This improves code maintainability and consistency.For even better consistency, consider updating other methods in this class that might still be using direct selector references (e.g.,
selector.vendor.vDashboard) to use the newvendorDashboardconstant.Also applies to: 170-170
tests/pw/pages/wholesalePage.ts (1)
182-200: LGTM: Enhanced viewWholeSalePrice method with improved flexibility.The
viewWholeSalePricemethod has been significantly improved:
- Two new parameters (
canViewandproductDetails) have been added, allowing for more flexible testing scenarios.- The new logic correctly implements visibility checks based on these parameters.
These changes enhance the method's functionality and test coverage.
Consider adding the following test cases to ensure comprehensive coverage:
- Test with
canView = falseandproductDetails = false- Test with
canView = trueandproductDetails = false- Test with
canView = falseandproductDetails = trueThese additional test cases will help ensure that all combinations of the new parameters are properly handled.
tests/pw/fixtures/page.ts (3)
137-137: Approve with suggestion: Maintain consistency in property naming.The type definition for
WholesalePagehas been added correctly to thepagestype. However, to maintain consistency with other property names in the type definition, consider changing the property name to lowercase.Apply this change to maintain consistency:
- WholesalePage: WholesalePage; + wholesalePage: WholesalePage;
402-403: Approve with suggestion: Maintain consistency in fixture naming.The fixture definition for
WholesalePagehas been added correctly. However, to maintain consistency with other fixture names, consider changing the fixture name to lowercase.Apply this change to maintain consistency:
- WholesalePage: async ({ page }, use) => { + wholesalePage: async ({ page }, use) => { await use(new WholesalePage(page)); },
413-414: Consider removing commented-out code.The comments for exporting
testandexpecthave been modified to indicate that they are no longer active. However, it's generally a good practice to remove commented-out code entirely if it's no longer needed, as it can lead to confusion and clutter in the codebase.Consider removing these lines entirely if they are no longer needed:
-// export const test = page; -// export const expect = page.expect;If there's a specific reason for keeping these comments, please add an explanatory note to clarify their purpose.
tests/pw/pages/productQAPage.ts (1)
299-299: Approved: Method name casing corrected.The change from
clickAndWaitForLocatorTobeVisibletoclickAndWaitForLocatorToBeVisibleimproves adherence to camelCase naming conventions. This is a good catch and enhances code readability.Consider updating the method name in other parts of the codebase (if any) to maintain consistency. You can use the following command to find other occurrences:
rg "clickAndWaitForLocatorTobeVisible" --type typescripttests/pw/feature-map/feature-map.yml (4)
689-689: LGTM: Added Mangopay payment methodEnabling Mangopay as a payment method expands payment options for vendors and customers. This is a positive addition to the plugin's functionality.
Consider updating the plugin's documentation to reflect this new payment method option.
809-809: LGTM: Added Razorpay payment methodEnabling Razorpay as a payment method expands payment options for vendors and customers. This is a positive addition to the plugin's functionality.
Consider updating the plugin's documentation to reflect this new payment method option.
819-819: LGTM: Added bulk action capability for abuse reportsEnabling bulk actions on abuse reports will significantly improve the efficiency of report management for admins.
Consider updating the admin documentation to include instructions on how to use this new bulk action feature for abuse reports.
847-847: LGTM: Added bulk action capability for quotesEnabling bulk actions on quotes will significantly improve the efficiency of quote management for admins.
Consider updating the admin documentation to include instructions on how to use this new bulk action feature for quotes.
tests/pw/pages/basePage.ts (3)
Line range hint
1361-1365: Improved method documentation.The comment above the
addLocatorHandlermethod has been updated from "userful" to "useful", correcting a typo. This improves the overall documentation quality.Consider adding more details to the comment, such as explaining when this method should be called (e.g., "Call this method before the start of the test to handle randomly appearing popups").
Line range hint
1600-1608: Simplified implementation usingclickAndWaitForResponse.The
enableSwitcherAndWaitForResponsemethod has been updated to use theclickAndWaitForResponsemethod instead ofPromise.all. This change simplifies the code and makes it more consistent with other methods in the class.Consider adding a comment explaining the behavior when the switcher is already enabled (i.e., when the method returns an empty string).
Line range hint
1611-1619: Simplified implementation usingclickAndWaitForResponse.The
disableSwitcherAndWaitForResponsemethod has been updated to use theclickAndWaitForResponsemethod instead ofPromise.all. This change simplifies the code and makes it more consistent with other methods in the class.Consider adding a comment explaining the behavior when the switcher is already disabled (i.e., when the method returns an empty string).
tests/pw/utils/testData.ts (1)
1884-1907: Approved: New vendorStaff structure addedThe addition of the
vendorStaffobject withbasicMenu,basicMenuNames, andmenusarrays is a good structure for managing vendor staff permissions or capabilities. This clear separation between basic and advanced menu items can facilitate different levels of staff access.Suggestion for improvement:
Consider adding a brief comment above thevendorStaffobject to explain its purpose and how it relates to the rest of the data structure. This would enhance code readability and make it easier for other developers to understand the context of this new addition.Example:
// Defines menu access and capabilities for vendor staff members vendorStaff: { // ... (existing code) }tests/pw/tests/e2e/wholesale.spec.ts (2)
104-105: Address the TODO Comment Regarding Product CreationThere is a TODO comment indicating that the line should be replaced when the product edit PR is merged. To prevent this from being overlooked, consider tracking this task explicitly.
Would you like me to open a GitHub issue to track this TODO, or assist in updating the code once the dependent PR is merged?
153-155: Clarify Access Levels in Test DescriptionsThe test
'All users can see wholesale price'might benefit from clarification on which user roles are included. Explicitly stating the user roles involved (e.g., guest, customer, admin) can enhance test readability.Consider updating the test description:
- test('All users can see wholesale price', { tag: ['@pro', '@customer'] }, async () => { + test('All user roles can see wholesale price', { tag: ['@pro', '@customer'] }, async () => {
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (30)
- tests/pw/feature-map/feature-map.yml (15 hunks)
- tests/pw/fixtures/page.ts (4 hunks)
- tests/pw/pages/basePage.ts (4 hunks)
- tests/pw/pages/colorsPage.ts (1 hunks)
- tests/pw/pages/customerPage.ts (1 hunks)
- tests/pw/pages/menuManagerPage.ts (8 hunks)
- tests/pw/pages/productAdvertisingPage.ts (1 hunks)
- tests/pw/pages/productQAPage.ts (1 hunks)
- tests/pw/pages/refundsPage.ts (1 hunks)
- tests/pw/pages/reverseWithdrawsPage.ts (2 hunks)
- tests/pw/pages/selectors.ts (2 hunks)
- tests/pw/pages/settingPage.ts (1 hunks)
- tests/pw/pages/settingsPage.ts (1 hunks)
- tests/pw/pages/singleProductPage.ts (1 hunks)
- tests/pw/pages/vendorBookingPage.ts (2 hunks)
- tests/pw/pages/vendorDashboardPage.ts (1 hunks)
- tests/pw/pages/vendorPage.ts (4 hunks)
- tests/pw/pages/vendorStaffPage.ts (2 hunks)
- tests/pw/pages/vendorSubscriptionsPage.ts (1 hunks)
- tests/pw/pages/wholesalePage.ts (6 hunks)
- tests/pw/pages/withdrawsPage.ts (1 hunks)
- tests/pw/tests/e2e/dashboard.spec.ts (1 hunks)
- tests/pw/tests/e2e/vendorBooking.spec.ts (1 hunks)
- tests/pw/tests/e2e/vendorStaff.spec.ts (1 hunks)
- tests/pw/tests/e2e/vendorVerifications.spec.ts (0 hunks)
- tests/pw/tests/e2e/wholesale.spec.ts (4 hunks)
- tests/pw/utils/apiUtils.ts (2 hunks)
- tests/pw/utils/helpers.ts (1 hunks)
- tests/pw/utils/pwMatchers.ts (1 hunks)
- tests/pw/utils/testData.ts (3 hunks)
Files not reviewed due to no reviewable changes (1)
- tests/pw/tests/e2e/vendorVerifications.spec.ts
Files skipped from review due to trivial changes (9)
- tests/pw/pages/productAdvertisingPage.ts
- tests/pw/pages/refundsPage.ts
- tests/pw/pages/settingsPage.ts
- tests/pw/pages/singleProductPage.ts
- tests/pw/pages/vendorBookingPage.ts
- tests/pw/pages/vendorSubscriptionsPage.ts
- tests/pw/pages/withdrawsPage.ts
- tests/pw/utils/helpers.ts
- tests/pw/utils/pwMatchers.ts
Additional context used
Biome
tests/pw/pages/menuManagerPage.ts
[error] 11-13: This constructor is unnecessary.
Unsafe fix: Remove the unnecessary constructor.
(lint/complexity/noUselessConstructor)
Additional comments not posted (45)
tests/pw/tests/e2e/dashboard.spec.ts (3)
Line range hint
1-55: Well-structured and consistent test suite. Good job!The test suite is well-organized with clear separation between admin and vendor tests. The new test case maintains consistency with existing tests in terms of structure and tagging. This addition enhances the coverage of vendor-related functionality.
The use of
beforeAllandafterAllhooks for setup and teardown is a good practice. The consistent use of tags (@lite,@exploratory,@vendor,@admin) across tests facilitates easy filtering and organization of test runs.
Line range hint
1-55: Summary: Focused addition enhancing vendor dashboard testingThis change introduces a new test case for vendor dashboard menus, which complements the existing vendor dashboard test. The addition is minimal, focused, and well-integrated into the existing test suite structure. It enhances the test coverage for vendor-related functionality without disrupting the existing tests.
The PR objectives align well with this change, as it contributes to enhancing the testing framework for the Pro module, specifically for vendor functionalities.
53-55: LGTM! Consider verifying the implementation of the new method.The new test case for vendor dashboard menus is a good addition that complements the existing vendor dashboard test. It follows the same structure and tagging convention as other tests in the suite.
To ensure the completeness of this change, please verify the implementation of the
vendorDashboardMenusRenderProperly()method in theVendorDashboardPageclass. You can use the following script to locate and review its implementation:Verification successful
Verified! The
vendorDashboardMenusRenderProperlymethod is properly implemented and aligns with the added test case. It comprehensively checks the visibility of all relevant dashboard menus based on the application’s configuration.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Locate and display the implementation of vendorDashboardMenusRenderProperly method # Search for the VendorDashboardPage class definition echo "VendorDashboardPage class definition:" ast-grep --lang typescript --pattern 'class VendorDashboardPage { $$$ }' # Search for the vendorDashboardMenusRenderProperly method echo "\nvendorDashboardMenusRenderProperly method implementation:" ast-grep --lang typescript --pattern 'async vendorDashboardMenusRenderProperly() { $$$ }'Length of output: 859
Script:
#!/bin/bash # Description: Locate and display the implementation of vendorDashboardMenusRenderProperly method # Search for the VendorDashboardPage class definition with a more flexible pattern echo "VendorDashboardPage class definition:" ast-grep --lang typescript --pattern 'class VendorDashboardPage { $$$ }' # Search for the vendorDashboardMenusRenderProperly method with adjusted pattern echo "\nvendorDashboardMenusRenderProperly method implementation:" ast-grep --lang typescript --pattern 'async vendorDashboardMenusRenderProperly($_parameters) { $$$ }' || \ echo "ast-grep pattern did not match. Attempting with ripgrep." # Alternative search using ripgrep if ast-grep fails echo "\nUsing ripgrep to locate vendorDashboardMenusRenderProperly method:" rg 'async\s+vendorDashboardMenusRenderProperly\s*\('Length of output: 1289
Script:
#!/bin/bash # Description: Locate and display the implementation of VendorDashboardPage class # Use ripgrep to find the VendorDashboardPage class definition echo "VendorDashboardPage class definition:" rg -A 10 'class\s+VendorDashboardPage' tests/pw/pages/vendorDashboardPage.tsLength of output: 452
Script:
#!/bin/bash # Description: Display the implementation of vendorDashboardMenusRenderProperly method # Use ripgrep to extract the method's implementation with context lines echo "vendorDashboardMenusRenderProperly method implementation:" rg -A 10 'async\s+vendorDashboardMenusRenderProperly\s*\(' tests/pw/pages/vendorDashboardPage.tsLength of output: 715
Script:
#!/bin/bash # Description: Retrieve the complete implementation of vendorDashboardMenusRenderProperly method # Use ripgrep to extract the full method implementation by specifying a range of lines echo "Complete vendorDashboardMenusRenderProperly method implementation:" rg -A 20 'async\s+vendorDashboardMenusRenderProperly\s*\(' tests/pw/pages/vendorDashboardPage.tsLength of output: 1295
tests/pw/pages/vendorDashboardPage.ts (1)
51-70: Good implementation, but consider some improvementsThe
vendorDashboardMenusRenderProperlymethod is well-structured and covers different scenarios based on theDOKAN_PROenvironment variable. However, there are a few points to consider:
Error handling: Consider adding try-catch blocks to handle potential errors if elements are not found.
Documentation: Add a comment explaining why 'inbox' and 'subscription' are excluded in the PRO version checks.
Non-PRO version checks: Verify if 'reverseWithdrawal' should be checked in the non-PRO version.
Here's a suggested improvement with error handling and comments:
async vendorDashboardMenusRenderProperly() { try { await this.goIfNotThere(data.subUrls.frontend.vDashboard.dashboard); await this.toBeVisible(vendorDashboard.menus.menus); if (DOKAN_PRO) { // Exclude 'inbox' and 'subscription' as they might be conditionally visible const { inbox, subscription, wepos, ...menus } = vendorDashboard.menus.primary; await this.multipleElementVisible(menus); } else { const nonProMenus = [ 'dashboard', 'products', 'orders', 'withdraw', 'settings', 'visitStore', 'editAccount' ]; for (const menu of nonProMenus) { await this.toBeVisible(vendorDashboard.menus.primary[menu]); } // Verify if 'reverseWithdrawal' should be checked in non-PRO version // await this.toBeVisible(vendorDashboard.menus.primary.reverseWithdrawal); } } catch (error) { console.error('Error in vendorDashboardMenusRenderProperly:', error); throw error; } }To verify the presence of 'reverseWithdrawal' in the non-PRO version, run the following script:
This will help determine if 'reverseWithdrawal' should be included in the non-PRO version checks.
tests/pw/pages/colorsPage.ts (4)
56-56: Typo correction approved.The comment has been corrected from "asertions" to "assertions", which improves code readability.
74-76: Assertion updates approved.The variable name in the assertions has been correctly updated from
beforHovertobeforeHover, maintaining consistency with the earlier variable name correction.
64-64: Variable name correction approved.The variable name has been corrected from
beforHovertobeforeHover, which improves code clarity and consistency.Please run the following script to ensure there are no remaining occurrences of the misspelled variable:
Verification successful
Please run the following script to ensure there are no remaining occurrences of the misspelled variable:
Variable name correction verified.
The variable name has been corrected from
beforHovertobeforeHover, and no remaining occurrences ofbeforHoverwere found in the codebase.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining occurrences of 'beforHover' # Test: Search for 'beforHover'. Expect: No results. rg --type typescript 'beforHover'Length of output: 474
Script:
#!/bin/bash # Description: Check for any remaining occurrences of 'beforHover' in TypeScript files # Test: Search for 'beforHover' in .ts and .tsx files. Expect: No results. rg 'beforHover' --glob '*.ts' --glob '*.tsx'Length of output: 44
69-72: Menu selector updates approved.The dashboard menu selectors have been updated to reflect a more specific structure (e.g.,
dashboardVendor.menus.primary.dashboardinstead ofdashboardVendor.menus.dashboard). This change likely accommodates a more complex menu hierarchy.Please run the following script to verify the new selector structure:
Verification successful
Menu selector updates verified successfully.
The new menu selector structures have been confirmed, and the old selectors are no longer present in the codebase.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the new menu selector structure # Test 1: Check for the existence of the new selector structure ast-grep --lang typescript --pattern 'dashboardVendor.menus.primary.$_' # Test 2: Ensure there are no remaining occurrences of the old selector structure rg --type typescript 'dashboardVendor\.menus\.(dashboard|settings)\b'Length of output: 474
Script:
#!/bin/bash # Description: Re-verify the absence of old menu selector structures without relying on predefined file types # Test 1: Check for the existence of the new selector structure ast-grep --lang typescript --pattern 'dashboardVendor.menus.primary.$_' # Test 2: Ensure there are no remaining occurrences of the old selector structure by explicitly searching .ts files rg 'dashboardVendor\.menus\.(dashboard|settings)\b' --glob '*.ts'Length of output: 435
tests/pw/pages/vendorStaffPage.ts (1)
9-9: LGTM: New constant for vendor dashboard selector.The addition of the
vendorDashboardconstant is appropriate and consistent with the existing code style. It provides a clear reference to the vendor dashboard selectors, which will be useful in the newly addedviewPermittedMenusmethod.tests/pw/pages/settingPage.ts (1)
47-50: LGTM! Verify other occurrences of the old selector.The update to the selector in the
disableVendorSetupWizardSettingmethod looks good. It reflects a possible restructuring of the dashboard menu, introducing a more specificprimarysubmenu.To ensure consistency across the test suite, please run the following script to check for any other occurrences of the old selector that might need updating:
If any occurrences are found, please review them to determine if they also need to be updated to use the new
primarysubmenu structure.Verification successful
Verification Complete: No other occurrences of the old selector found.
All instances of the old selector
selector.vendor.vDashboard.menus.dashboardhave been successfully updated toselector.vendor.vDashboard.menus.primary.dashboard. No further action is required.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for other occurrences of the old dashboard selector # Test: Search for the old selector pattern echo "Searching for occurrences of the old selector pattern:" rg --type typescript "selector\.vendor\.vDashboard\.menus\.dashboard" echo "Searching for similar selector patterns that might need updating:" rg --type typescript "selector\.vendor\.vDashboard\.menus\.[a-zA-Z]+"Length of output: 473
Script:
#!/bin/bash # Description: Search for other occurrences of the old dashboard selector with corrected file type # Test: Search for the old selector pattern echo "Searching for occurrences of the old selector pattern with type 'ts':" rg --type ts "selector\.vendor\.vDashboard\.menus\.dashboard" echo "Searching for similar selector patterns that might need updating with type 'ts':" rg --type ts "selector\.vendor\.vDashboard\.menus\.[a-zA-Z]+"Length of output: 688
tests/pw/pages/menuManagerPage.ts (6)
8-8: LGTM: Good use of a constant for the vendor dashboard selector.This change improves code readability and maintainability by centralizing the selector reference. It's consistent with the existing pattern of using constants for selectors.
38-38: LGTM: Consistent use of the newvendorDashboardconstant.This change aligns with the introduction of the
vendorDashboardconstant, improving code consistency and maintainability.
49-49: LGTM: Consistent use of thevendorDashboardconstant.This change maintains consistency with the previous updates, further improving code readability and maintainability.
61-61: LGTM: Improved code organization and consistency.The changes in the
renameMenumethod:
- Use the new
goToMenuManagerSettingsmethod, reducing code duplication and improving maintainability.- Consistently use the
vendorDashboardconstant, aligning with previous updates.These modifications enhance the overall code quality and readability.
Also applies to: 71-71
75-75: LGTM: Consistent use of the new navigation method.The
cantRenameMenuBeyondLimitandcantRenameMenumethods now use thegoToMenuManagerSettingsmethod for navigation. This change:
- Reduces code duplication.
- Improves maintainability by centralizing navigation logic.
- Maintains consistency across the class.
Also applies to: 88-88
95-95: LGTM: Consistent improvements across multiple methods.The changes in
cantAlterMenu,reorderMenu, andresetMenuManagerSettingsmethods:
- Consistently use the new
goToMenuManagerSettingsmethod, reducing code duplication and centralizing navigation logic.- In
reorderMenu, thevendorDashboardconstant is used consistently, aligning with previous updates.These changes contribute to improved code organization, readability, and maintainability throughout the class.
Also applies to: 104-104, 118-119, 127-127
tests/pw/pages/reverseWithdrawsPage.ts (2)
11-11: LGTM: Good use of a constant for the vendor dashboard selector.The introduction of the
vendorDashboardconstant is a positive change. It centralizes the reference to the vendor dashboard selector, which can improve code maintainability and readability. The naming convention is also consistent with JavaScript/TypeScript best practices.
Line range hint
1-190: Summary: Changes align well with PR objectives and improve code quality.The introduced changes in this file contribute positively to the PR's objective of enhancing the testing framework for the Pro module. The addition of the
vendorDashboardconstant and its subsequent use in thevendorCantWithdrawandvendorStatusInactivemethods improve code maintainability and readability.These changes are consistent with best practices for test automation and will likely make future updates to vendor dashboard selectors easier to manage. The modifications align well with the goal of adding automated tests for wholesale and vendor staff functionalities in the Pro module.
tests/pw/pages/wholesalePage.ts (7)
11-11: LGTM: Consistent selector renaming.The change from
wholesaleCustomersAdmintowholesaleAdminaligns with the class renaming mentioned in the summary. This improves consistency throughout the file.
29-41: LGTM: Consistent selector updates.The changes in the
adminWholesaleCustomersRenderProperlymethod correctly update all occurrences ofwholesaleCustomersAdmintowholesaleAdmin, maintaining consistency with the earlier selector renaming.
47-50: LGTM: Consistent selector updates in searchWholesaleCustomer method.The changes in the
searchWholesaleCustomermethod correctly update all occurrences ofwholesaleCustomersAdmintowholesaleAdmin, maintaining consistency with the earlier selector renaming.
56-57: LGTM: Consistent selector updates in editWholesaleCustomer method.The changes in the
editWholesaleCustomermethod correctly update all occurrences ofwholesaleCustomersAdmintowholesaleAdmin, maintaining consistency with the earlier selector renaming.
114-115: LGTM: Consistent selector updates across multiple methods.The changes in the
viewWholesaleCustomerOrders,updateWholesaleCustomer, andwholesaleCustomerBulkActionmethods correctly update all occurrences ofwholesaleCustomersAdmintowholesaleAdmin, maintaining consistency with the earlier selector renaming.Also applies to: 125-125, 129-129, 133-134, 151-151, 153-155
Line range hint
1-214: Overall assessment: Well-structured and consistent changes.The changes in this file align well with the PR objectives of enhancing the testing framework for the Pro module. The renaming of the class and selectors has been consistently applied throughout the file, improving readability and maintainability. The enhanced
viewWholeSalePricemethod provides more flexible testing scenarios, which is a valuable addition to the test suite.Key points:
- Consistent renaming of
WholesaleCustomersPagetoWholesalePageand related selectors.- Improved flexibility in the
viewWholeSalePricemethod with new parameters.- No major issues were identified during the review.
Great job on these improvements!
14-14: LGTM: Class renaming is consistent.The class renaming from
WholesaleCustomersPagetoWholesalePageis consistent with the AI summary. This change improves the naming convention.Please verify that all import statements in other files using this class have been updated accordingly. Run the following script to check for any remaining references to the old class name:
tests/pw/fixtures/page.ts (2)
67-67: LGTM: Import statement for WholesalePage added correctly.The import statement for
WholesalePagehas been added correctly, following the established pattern in the file. This change aligns with the PR objectives of adding tests for the wholesale functionality.
Line range hint
1-414: Summary: WholesalePage integration successful with minor suggestions.The changes to integrate the
WholesalePageinto the test fixtures have been implemented successfully. These modifications align well with the PR objectives of adding tests for the wholesale functionality. To further improve the code quality and consistency, please consider the following recommendations:
- Maintain consistent naming conventions by using lowercase for property and fixture names (e.g.,
wholesalePageinstead ofWholesalePage).- Remove or provide explanations for the commented-out code at the end of the file.
Overall, the changes look good and achieve the intended purpose of adding support for wholesale functionality testing.
tests/pw/pages/productQAPage.ts (1)
Line range hint
1-303: Overall, theProductQAPageclass is well-structured and comprehensive.The class provides a robust set of methods for testing various aspects of the product Q&A functionality, including admin, vendor, and customer interactions. The use of selectors and helper methods promotes maintainability and readability. The recent change to correct the method name casing further improves the code quality.
tests/pw/pages/vendorPage.ts (4)
18-18: LGTM: Improved code maintainabilityThe introduction of the
vendorDashboardconstant centralizes the reference to the vendor dashboard selector. This change can improve code maintainability by reducing duplication and making it easier to update the selector in the future if needed.
213-213: LGTM: Consistent use of the new constantThe modification to use
vendorDashboard.menus.primary.dashboardis consistent with the introduction of thevendorDashboardconstant. This change improves code readability and maintainability.
250-250: LGTM: Consistent use of the new constantThe modification to use
vendorDashboard.atAGlance.earningValueis consistent with the introduction of thevendorDashboardconstant. This change improves code readability and maintainability.
317-320: LGTM: Consistent use of the new constantThe modifications to use
vendorDashboard.menus.primary.visitStoreare consistent with the introduction of thevendorDashboardconstant. These changes improve code readability and maintainability while preserving the original logic of the method.tests/pw/pages/customerPage.ts (1)
128-128: Selector update looks good, verify consistency across codebase.The change to use
selector.vendor.vDashboard.menus.primary.dashboardreflects an update in the vendor dashboard menu structure. This modification appears to be correct and more specific.To ensure consistency, let's check if this new selector is used correctly across the codebase:
Verification successful
Selector update is consistent across the codebase.
All usages have been updated to
selector.vendor.vDashboard.menus.primary.dashboard, and there are no remaining references to the old selector.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usage of the new selector structure rg "selector\.vendor\.vDashboard\.menus\.primary" --type typescript # Search for any remaining usage of the old selector structure rg "selector\.vendor\.vDashboard\.menus\.dashboard" --type typescriptLength of output: 211
Script:
#!/bin/bash # Search for usage of the new selector structure rg "selector\.vendor\.vDashboard\.menus\.primary" -g "*.ts" # Search for any remaining usage of the old selector structure rg "selector\.vendor\.vDashboard\.menus\.dashboard" -g "*.ts"Length of output: 354
tests/pw/feature-map/feature-map.yml (4)
79-79: LGTM: Enhanced vendor dashboard functionalityThis change allows vendors to view dashboard menus in the lite version, which is a positive enhancement to the vendor experience.
693-695: LGTM: Enhanced vendor product management capabilitiesThese changes allow vendors to add min-max options for products and set min-max settings, which provides more flexibility in product management.
To ensure these new features work as expected, please add appropriate test cases. You can use the following command to check for existing tests related to these features:
#!/bin/bash # Check for existing tests related to min-max options and settings grep -rn "test.*min-max" tests/If no relevant tests are found, consider adding new ones to cover these scenarios.
901-902: LGTM: Added ShipStation settings capability for vendorsAllowing vendors to set ShipStation settings will improve their ability to manage shipping effectively.
To ensure this new feature works as expected, please add appropriate test cases. You can use the following command to check for existing tests related to this feature:
#!/bin/bash # Check for existing tests related to ShipStation settings grep -rn "test.*shipStation" tests/If no relevant tests are found, consider adding new ones to cover this scenario.
Update the vendor documentation to include instructions on how to use this new ShipStation settings feature.
999-1003: LGTM: Enhanced shipping methods and wholesale featuresThese changes introduce new shipping methods (table rate and distance rate) for both admins and vendors, and modify wholesale pricing visibility and purchasing for customers. These enhancements provide more flexibility in shipping options and improve the wholesale experience.
To ensure these new features work as expected, please add appropriate test cases. You can use the following commands to check for existing tests related to these features:
If no relevant tests are found, consider adding new ones to cover these scenarios.
Update the admin, vendor, and customer documentation to reflect these new shipping methods and wholesale feature changes.
Also applies to: 1107-1109
Verification successful
: Tests for shipping methods and wholesale features are present.
All necessary test cases for the new shipping methods and wholesale features have been found and are in place.
Please update the admin, vendor, and customer documentation to reflect these changes.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for existing tests related to new shipping methods grep -rn "test.*table rate shipping" tests/ grep -rn "test.*distance rate shipping" tests/ # Check for existing tests related to wholesale features grep -rn "test.*wholesale price" tests/ grep -rn "test.*wholesale product" tests/Length of output: 1595
tests/pw/pages/basePage.ts (2)
195-197: Method name corrected for better readability.The method name has been updated from
clickAndWaitForLocatorTobeVisibletoclickAndWaitForLocatorToBeVisible. This change improves readability by correctly capitalizing "Be" in the method name.
Line range hint
1-1777: Overall improvements in code quality and consistency.The changes made to this file are minimal but positive. They improve code readability, correct typos, and simplify implementations. The updates align well with the existing codebase and maintain consistency across methods.
To further enhance the file:
- Consider adding more detailed comments for complex methods.
- Review other similar methods in the class for potential simplification using the
clickAndWaitForResponsepattern.- Ensure all method names follow the same capitalization convention (e.g.,
toBeVisiblevsToBeVisible).tests/pw/utils/apiUtils.ts (3)
1318-1336: Improved vendor staff creation with additional return valueThe
createVendorStafffunction has been successfully updated to include thestaffNamein its return values. This enhancement provides more detailed information about the created or updated staff member, improving the function's utility.Key improvements:
- The function now handles both new staff creation and existing staff updates.
- Error handling is in place for cases where the staff member already exists.
- The
staffNameis correctly assigned in both creation and update scenarios.- The return statement has been updated to include the new
staffNamevalue.These changes enhance the function's functionality and align with the PR objectives of improving the Pro module tests.
1345-1349: New function added for updating staff capabilitiesThe
updateStaffCapabilitiesfunction is a valuable addition to theApiUtilsclass. This new function enhances the vendor management capabilities by allowing the update of staff member permissions.Key points:
- The function follows the established pattern of other API utility methods in the class.
- It provides a clear and concise way to update staff capabilities using a PUT request.
- The function signature includes all necessary parameters:
staffId,payload, and optionalauth.- It returns a
Promise<responseBody>, maintaining consistency with other API methods.This addition aligns well with the PR objectives of enhancing the Pro module tests, particularly for vendor staff functionality.
Line range hint
1-1350: Summary of changes: Enhanced vendor staff management capabilitiesThe modifications to this file have successfully improved the vendor staff management functionality within the
ApiUtilsclass. The key changes are:
Updated
createVendorStafffunction (lines 1318-1336):
- Now returns an additional
staffNamevalue.- Improved handling of both new staff creation and existing staff updates.
Added new
updateStaffCapabilitiesfunction (lines 1345-1349):
- Allows updating of staff member permissions.
- Follows the established pattern of other API utility methods.
These changes align well with the PR objectives of enhancing the Pro module tests, specifically for wholesale and vendor staff functionalities. The modifications are consistent with the existing code style and patterns, maintaining the overall integrity of the
ApiUtilsclass.The enhancements provide more detailed information and greater flexibility in managing vendor staff, which should facilitate more comprehensive testing and improved vendor management capabilities.
tests/pw/utils/testData.ts (2)
922-922: Approved: Improved naming consistencyThe changes from
bookedDayBlockestobookedDayBlocksandfullnametofullNameare good improvements. They enhance code consistency and adhere to common naming conventions in JavaScript/TypeScript.
bookedDayBlocks: Corrects the plural form and matches the camelCase convention.fullName: Follows the camelCase convention for compound words.These small changes can significantly improve code readability and reduce potential confusion for developers working with this data structure.
Also applies to: 1442-1442
Line range hint
1-2275: Final review: File structure and changes are appropriateAfter reviewing the entire file, I can confirm that the changes made improve the code quality without introducing any new issues. The file maintains a consistent structure, and the additions fit well within the existing
dataobject.Key points:
- Naming inconsistencies were corrected (
bookedDayBlocksandfullName).- A new
vendorStaffobject was added with a clear structure for managing staff capabilities.- The overall organization of the
dataobject remains logical and easy to navigate.The file appears to be in good shape, with the recent changes enhancing its maintainability and consistency.
tests/pw/tests/e2e/wholesale.spec.ts (1)
86-86: Verify the Method 'updateOptionValue'The method
dbUtils.updateOptionValueis used to update the wholesale settings. Ensure that this method exists and is the correct choice oversetOptionValue. Confirm that it updates the options as intended.You can run the following script to verify the method's presence and usage:
Verification successful
Verified the
updateOptionValuemethod exists and is correctly utilized in the codebase.
- Method
updateOptionValueis defined intests/pw/utils/dbUtils.ts.- It is actively used across multiple test files to update various settings, confirming it functions as intended.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if 'updateOptionValue' method exists in dbUtils. # Test: Search for 'updateOptionValue' method definition. # Expect: Method definition should be found in dbUtils module. rg --type js 'updateOptionValue' $(fd dbUtils.js)Length of output: 49
Script:
#!/bin/bash # Search for all JavaScript files related to dbUtils fd 'dbUtils' --type f --extension js # Search for the 'updateOptionValue' method across the entire codebase rg --type js 'updateOptionValue'Length of output: 69
Script:
#!/bin/bash # Search for all JavaScript and TypeScript files related to dbUtils fd 'dbUtils' --type f --extension js --extension ts # Search for the 'updateOptionValue' method across JavaScript and TypeScript files rg --type js --type ts 'updateOptionValue'Length of output: 6926
| let customer: WholesaleCustomersPage; | ||
| test.describe('Wholesale test (admin)', () => { | ||
| let admin: WholesalePage; | ||
| let customer: WholesalePage; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Potential Confusion with Variable 'customer' Typed as 'WholesalePage'
In the 'Wholesale test (admin)' suite, the variable customer is declared as WholesalePage, which might be confusing since it represents a customer context. To improve clarity, consider renaming the variable to reflect its purpose or verifying if it should be of type CustomerPage.
shashwatahalder01
added
QA approved
* Add Pro module tests(wholesale, vendorstaff) (test automation) (getdokan#2379) * Add Wholesale module tests * Update featureMap * Add vendor staff & menu tests * Fix locator issue * Fix typos * Update featureMap * Rename context * Update: Refactor base-page methods * Add: add new setup tests to both e2e & api suite * Update: revert typescript version * Fix: fix a flaky test * Add: add new helper methods * Update: update feature-map * Update: update test-data & interface * Update: remove a method * Fix: fix a failed test * Fix: resolve pr reviews
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
New Features
Bug Fixes
Tests