Add Booking products tests #2438
Conversation
WalkthroughThe pull request introduces significant modifications across multiple files, primarily enhancing the functionality and organization of booking and product management features. Key changes include the restructuring of the Changes
Possibly related PRs
Poem
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: 19
🧹 Outside diff range and nitpick comments (22)
tests/pw/tests/e2e/vendorBooking.spec.ts (2)
Line range hint
127-127: Fix timezone-dependent test failure.The TODO comment indicates a timezone-related failure in CI. This could lead to flaky tests.
Consider these solutions:
- Mock the system time in the test
- Make the test timezone-independent by using relative times
- Explicitly set the timezone in the test environment
Example fix:
// Before running the test, set a fixed time test.beforeAll(async ({ browser }) => { // Set timezone to UTC to ensure consistent behavior process.env.TZ = 'UTC'; }); // In the test, use relative times instead of absolute times const bookingDate = new Date(); bookingDate.setDate(bookingDate.getDate() + 1); // Book for tomorrow
Line range hint
1-127: Overall test structure looks good!Positive aspects of the test suite:
- Well-organized test cases with clear separation of concerns
- Proper use of page object model
- Good test isolation with separate browser contexts
- Comprehensive coverage of booking functionality
- Appropriate use of tags for test categorization
Minor suggestions:
- Consider adding more assertions in the test cases
- Add error handling for API calls in setup
tests/pw/tests/e2e/productsDetailsAuction.spec.ts (2)
244-245: Consider adding details to the TODO comment.The TODO comment lacks specificity about what needs to be refactored. Consider either:
- Adding specific details about the refactoring needed
- Creating a GitHub issue to track the refactoring task
- Removing the comment if it's no longer relevant
Would you like me to help create a GitHub issue to track this refactoring task?
172-173: Consider optimizing test performance.Multiple tests create new products when testing different features. While this ensures test isolation, it might impact execution time. Consider:
- Grouping related tests and reusing products where isolation isn't critical
- Using beforeEach hooks for common setup
- Implementing parallel test execution for independent test cases
Example optimization for virtual option tests:
test.describe('Product virtual options', () => { + let productId: string; + + test.beforeEach(async () => { + [, productId] = await apiUtils.createProduct(payloads.createAuctionProductRequiredFields(), payloads.vendorAuth); + }); + test('vendor can add product virtual option', async () => { - const [, productIdFull] = await apiUtils.createProduct(payloads.createAuctionProductRequiredFields(), payloads.vendorAuth); - await vendor.addProductVirtualOption(productIdFull, true); + await vendor.addProductVirtualOption(productId, true); }); });Also applies to: 177-178, 248-249, 255-256, 263-264, 296-297, 301-302
tests/pw/tests/e2e/productsDetails.spec.ts (1)
439-439: Organize and complete test coverage.Several TODO comments indicate:
- Duplicate tests that should be consolidated (EU compliance, product addons)
- Missing test coverage (advertising, rank math SEO, variation options)
- Missing update RMA options tests
Consider:
- Moving duplicate tests to shared test suites
- Creating a tracking issue for the missing test coverage
Would you like me to:
- Create a proposal for reorganizing the duplicate tests?
- Open a GitHub issue to track the missing test coverage?
Also applies to: 452-452, 494-494, 531-533
tests/pw/pages/vendorAuctionsPage.ts (1)
Line range hint
588-593: LGTM! Consider adding error handling.The implementation correctly verifies that an already added attribute cannot be added again. The method name is descriptive, and the assertions are appropriate for checking both visibility and disabled state.
Consider adding error handling for cases where the product or attribute doesn't exist:
async cantAddAlreadyAddedAttribute(productName: string, attributeName: string): Promise<void> { await this.goToAuctionProductEditById(productName); + try { await this.toBeVisible(productsVendor.attribute.savedAttribute(attributeName)); await this.toHaveAttribute(productsVendor.attribute.disabledAttribute(attributeName), 'disabled', 'disabled'); + } catch (error) { + throw new Error(`Failed to verify attribute "${attributeName}" for product "${productName}": ${error.message}`); + } }tests/pw/pages/selectors.ts (1)
5232-5238: LGTM! Consider minor improvement for consistency.The tag selector implementation looks good and follows the established patterns. However, for better consistency with other tag selectors in the codebase, consider using a single selector pattern instead of the OR condition.
- tagInput: '//select[@id="product_tag_edit"]/..//input[@class="select2-search__field"] | //select[@id="product_tag[]"]/..//input[@class="select2-search__field"]', // todo: remove previous when pr merged + tagInput: '//select[@id="product_tag[]"]/..//input[@class="select2-search__field"]',tests/pw/tests/e2e/productsDetailsBookings.spec.ts (6)
44-46: Avoid re-creating 'productIdFull'; reuse the existing one.In this test,
productIdFullis re-created even though it was created in thebeforeAllhook. This can lead to unnecessary API calls and potential inconsistencies. Consider reusing the existingproductIdFull.Modify the test to use the existing
productIdFull:- const [, productIdFull] = await apiUtils.createBookableProduct(payloads.createBookableProduct(), payloads.vendorAuth); - await vendor.addProductTitle(productIdFull, data.product.productInfo.title); + await vendor.addProductTitle(productIdFull, data.product.productInfo.title);
51-57: Ensure consistent product ID usage across tests.In tests for updating product categories, you're using both
productIdFullandproductIdBasic. For clarity and consistency, consider using a single product ID unless different setups are required.Consolidate the tests to use
productIdFull:- await vendor.addProductCategory(productIdBasic, data.product.category.categories, true); + await vendor.addProductCategory(productIdFull, data.product.category.categories, true);
84-86: Address skipped test due to Dokan issue.The test is skipped with the message 'dokan issue option does not work'. To ensure full coverage, consider addressing the underlying issue or tracking it appropriately.
Would you like assistance in diagnosing the Dokan issue or creating a GitHub issue to track it?
370-372: Avoid using 'test.slow()' without a parameter.The
test.slow()method should be used with a boolean parameter or inside a test modifier. Using it without parameters may not have the intended effect.Update the line to specify the intended behavior:
- test.slow(); + test.slow(true);
230-230: Remove unnecessary empty lines for cleaner code.There's an extra empty line here that can be removed to improve code readability.
352-352: Remove completed 'TODO' comments.The comment
// todo: vendor can't add already added attributeseems to be a placeholder. If this test is already implemented or no longer needed, consider removing the comment.tests/pw/utils/interfaces.ts (2)
255-263: Consider simplifying property names within 'duration'Since the properties are within the
durationobject, prefixes likebookingDurationmight be redundant. You could rename the properties totype,duration,unit,min, andmaxfor better readability.
266-275: Simplify property names within 'availability'The property names within the
availabilityobject could be simplified to enhance readability. For example,minimumBookingWindowIntoTheFutureDatecould be renamed tominBookingWindoworminAdvanceBooking.tests/pw/pages/vendorBookingPage.ts (4)
339-360: Improve Parameter Naming for ClarityThe parameter
neginvendorAddProductCategoryis not immediately descriptive.Consider renaming
negto something more expressive likeexpectDisabledorshouldBeDisabledto enhance readability.-async vendorAddProductCategory(category: string, multiple: boolean, neg?: boolean): Promise<void> { +async vendorAddProductCategory(category: string, multiple: boolean, expectDisabled?: boolean): Promise<void> { ... - if (neg) { + if (expectDisabled) { await this.toBeDisabled(productsVendor.category.done); return; }
428-432: Possible Unhandled Promise RejectionWhen removing the previous cover image, ensure that the actions are properly awaited and error-handled.
Consider adding error handling or checks to confirm that the image has been removed before proceeding.
157-161: Redundant Comments and Missing Error HandlingThe comments within
updateBookingProductFields(e.g.,// booking duration options) are redundant with the code itself. Additionally, there's no error handling if any of the fields fail to update.Consider removing redundant comments and adding error handling to verify each field update.
697-697: Unused ConditionhasClassinaddProductTaxThe parameter
hasClasscontrols whether to select a tax class, but it's not clear wherehasClassis set or used elsewhere.Consider evaluating if
hasClassis necessary or if it can be determined based ontax.class.tests/pw/utils/testData.ts (1)
406-406: Replace hardcoded 'addResourceId' with the actual resource IDThe
addResourceIdis currently set to'427'with a TODO comment. Please update this to use the correct dynamic value to ensure proper functionality.tests/pw/utils/payloads.ts (2)
987-990: Remove unnecessary commented-out codeLines 987-990 contain commented-out properties (
min_date_value,min_date_unit,max_date_value,max_date_unit). If these properties are no longer needed, consider removing them to enhance code readability. If they are intended for future use, you might want to add a comment explaining their purpose.
1012-1012: Ensure consistent property naming fordisplay_costThe property
display_costuses snake_case, whereas similar properties may use camelCase in the codebase (e.g.,displayCostininterfaces.ts). To maintain consistency across the codebase, consider renaming it todisplayCost.Apply this diff to update the property name:
- display_cost: '15', + displayCost: '15',
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (11)
tests/pw/pages/productsPage.ts(1 hunks)tests/pw/pages/selectors.ts(4 hunks)tests/pw/pages/vendorAuctionsPage.ts(1 hunks)tests/pw/pages/vendorBookingPage.ts(5 hunks)tests/pw/tests/e2e/productsDetails.spec.ts(4 hunks)tests/pw/tests/e2e/productsDetailsAuction.spec.ts(3 hunks)tests/pw/tests/e2e/productsDetailsBookings.spec.ts(1 hunks)tests/pw/tests/e2e/vendorBooking.spec.ts(1 hunks)tests/pw/utils/interfaces.ts(1 hunks)tests/pw/utils/payloads.ts(2 hunks)tests/pw/utils/testData.ts(2 hunks)
🔇 Additional comments (10)
tests/pw/tests/e2e/vendorBooking.spec.ts (1)
34-35: Verify test isolation with RMA settings.
The addition of RMA settings in the setup might affect other test suites. Consider:
- Resetting these settings in
afterAll - Moving this to a more specific setup if it's not required for all tests
✅ Verification successful
Test cleanup is properly handled
The RMA settings are properly managed in both test files:
vendorSettings.spec.tsresets RMA settings in itsafterAllhookvendorBooking.spec.tshas anafterAllhook for cleanup, and since it's disabling the settings, no reset is needed- Both files properly isolate their RMA settings changes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if RMA settings are used in other test files
# Expected: No other test files should rely on these settings
# Search for RMA settings usage in test files
rg -t ts "_dokan_rma_settings" tests/
Length of output: 710
Script:
#!/bin/bash
# Let's check the content of vendorSettings.spec.ts to see if it handles cleanup
rg -A 10 -B 10 "_dokan_rma_settings" tests/pw/tests/e2e/vendorSettings.spec.ts
# Also check if there are any afterAll hooks in vendorBooking.spec.ts
rg -A 10 "afterAll" tests/pw/tests/e2e/vendorBooking.spec.ts
# Check the RMA settings structure in test data
rg -A 5 "rmaSettings" tests/pw/utils/dbData.ts
Length of output: 1723
tests/pw/tests/e2e/productsDetailsAuction.spec.ts (1)
16-17: LGTM! Improved variable naming for better clarity.
The renaming from productId to productIdFull and productId1 to productIdBasic makes the purpose of each variable clearer, with helpful comments indicating their differences.
tests/pw/tests/e2e/productsDetails.spec.ts (2)
19-20: Improved variable naming for better clarity!
The renaming of variables from productName to productNameFull and productName1 to productNameBasic better reflects their purpose, and the added comments provide clear context about their differences.
32-33: Address the media URL handling in GitHub Actions.
The commented code and TODO suggest an unresolved issue with media URL handling in GitHub Actions. This could affect test coverage for image-related functionality.
Let's check if this is a known issue:
Would you like me to help create a GitHub issue to track this media URL handling problem?
tests/pw/pages/selectors.ts (1)
Line range hint 5249-5283: LGTM! Well-structured booking configuration selectors.
The booking configuration selectors are well organized and follow consistent naming patterns. The selectors appropriately use IDs where available and fall back to other selector types when needed. The comments explaining options (e.g. for status values) are helpful.
tests/pw/utils/interfaces.ts (1)
276-280: Costs object is well-structured
Grouping cost-related properties under the costs object improves code organization and clarity.
tests/pw/pages/vendorBookingPage.ts (2)
323-327: Consistency in Success Messages
The success message in saveProduct differs from others.
Ensure that the success message 'Success! The product has been saved successfully.' is consistent across the application.
#!/bin/bash
# Description: Verify consistency of success messages in the codebase.
rg -F "'Success! The product has been saved successfully.'" tests/pw/pages/
# Expected: The success message should match in all relevant files.64-66: Potential Misuse of data.subUrls.frontend.vDashboard.bookingProductEdit
Ensure that productId is correctly used to construct the URL in gotoUntilNetworkidle. If productId is actually a productName, this could cause navigation issues.
Run the following script to verify that all calls to goToBookingProductEditById pass a valid productId:
tests/pw/utils/testData.ts (2)
1154-1154: Verify usage consistency of 'bookingProductEdit' method
The method bookingProductEdit(productId: string) has been added to the vDashboard. Ensure that this method is consistently implemented across the codebase and that any calls to edit booking products utilize this new method.
Run the following script to check for method usage:
#!/bin/bash
# Description: Find all usages of 'bookingProductEdit' to verify consistency.
# Expected Result: All instances align with the new method implementation.
rg 'bookingProductEdit\(.*\)'366-393: 🛠️ Refactor suggestion
Ensure all references to booking properties are updated to the new nested structure
The booking object has been reorganized with properties grouped into nested objects: duration, availability, costs, and extraOptions. Please verify that all code referencing these properties has been updated to reflect the new structure to prevent any runtime errors.
Run the following script to find any outdated references:
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
tests/pw/utils/payloads.ts (1)
993-1040: Consider adding validation for display_costThe implementation looks good and properly extends the base bookable product configuration. The addition of
display_costprovides flexibility in pricing display.Consider adding validation to ensure
display_costis always greater than or equal to the basecost. This would prevent potential pricing inconsistencies.Example validation:
if (parseFloat(display_cost) < parseFloat(cost)) { throw new Error('Display cost cannot be less than base cost'); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
tests/pw/tests/e2e/productsDetails.spec.ts(8 hunks)tests/pw/tests/e2e/productsDetailsAuction.spec.ts(6 hunks)tests/pw/tests/e2e/productsDetailsBookings.spec.ts(1 hunks)tests/pw/utils/payloads.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- tests/pw/tests/e2e/productsDetails.spec.ts
- tests/pw/tests/e2e/productsDetailsAuction.spec.ts
- tests/pw/tests/e2e/productsDetailsBookings.spec.ts
🔇 Additional comments (1)
tests/pw/utils/payloads.ts (1)
Line range hint 965-993: Fix property name and approve structure
The method structure looks good and includes all necessary fields for a bookable product. However, there's a property name issue that needs to be fixed.
Apply this diff to fix the property name:
- requires_confirmations: false,
+ requires_confirmation: false,
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (4)
tests/pw/tests/e2e/productsDetailsBookings.spec.ts (3)
30-30: Enhance test coverage by implementing all fields inpayloads.createBookableProduct().The TODO comment indicates incomplete test coverage. This could lead to missing edge cases or potential issues in the product creation process.
Would you like me to help implement the missing fields in the payload or create a GitHub issue to track this task?
304-307: Implement skipped resource-related tests.Multiple tests for resource management are skipped with TODO comments. This leaves a gap in testing coverage for an important feature of booking products.
Would you like me to help implement these tests or create a GitHub issue to track this task? The implementation should include:
- Creating products with resources
- Updating resource configurations
- Proper cleanup of resources
Also applies to: 309-312, 314-318
1-388: Overall test suite structure looks good.The test suite is well-organized with clear test descriptions and logical grouping of related tests. The use of beforeAll/afterAll hooks for setup and cleanup is appropriate.
Consider these improvements:
- Add error boundary tests for edge cases
- Implement data-driven tests for variations
- Add performance benchmarks for slow tests
tests/pw/pages/selectors.ts (1)
Line range hint
5249-5283: Improve organization of booking-related selectorsThe booking-related selectors are mixed with other product selectors. Consider grouping them logically for better maintainability.
Suggest reorganizing the selectors into a dedicated booking section:
booking: { // Basic booking options bookingDurationType: '#\\_wc_booking_duration_type', bookingDuration: 'input#\\_wc_booking_duration', bookingDurationUnit: '#\\_wc_booking_duration_unit', bookingDurationMin: 'input#\\_wc_booking_min_duration', bookingDurationMax: 'input#\\_wc_booking_max_duration', // Calendar options calendarDisplayMode: '#\\_wc_booking_calendar_display_mode', enableCalendarRangePicker: '#\\_wc_booking_enable_range_picker', // Booking rules requiresConfirmation: '#\\_wc_booking_requires_confirmation', canBeCancelled: '#\\_wc_booking_user_can_cancel', // ... other booking related selectors }This would:
- Improve code organization
- Make it easier to maintain booking-related selectors
- Provide better separation of concerns
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
tests/pw/pages/selectors.ts(5 hunks)tests/pw/pages/vendorAuctionsPage.ts(2 hunks)tests/pw/tests/e2e/productsDetailsAuction.spec.ts(6 hunks)tests/pw/tests/e2e/productsDetailsBookings.spec.ts(1 hunks)tests/pw/tests/e2e/storelisting.spec.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- tests/pw/tests/e2e/storelisting.spec.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- tests/pw/pages/vendorAuctionsPage.ts
- tests/pw/tests/e2e/productsDetailsAuction.spec.ts
🔇 Additional comments (1)
tests/pw/tests/e2e/productsDetailsBookings.spec.ts (1)
34-34:
Uncomment cleanup code to prevent test data pollution.
The cleanup code is commented out, which could lead to test data accumulation and potential interference between test runs.
Apply this change:
- // await apiUtils.deleteAllProducts(payloads.vendorAuth);
+ await apiUtils.deleteAllProducts(payloads.vendorAuth);Likely invalid or redundant comment.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (6)
tests/pw/tests/e2e/commission.spec.ts (1)
Line range hint
86-98: Review subscription product test implementationMultiple subscription-related tests are skipped pending implementation of
createDokanSubscriptionProduct. Consider:
- Creating a separate ticket for implementing this function
- Moving these tests to a PRO-specific test file
Would you like help in:
- Creating a separate test file for PRO features?
- Implementing the
createDokanSubscriptionProductfunction?tests/pw/pages/commissionPage.ts (2)
33-35: Fix indentation in the if block.While the logic change to explicit visibility checking is good, the indentation is inconsistent with the rest of the file.
- if (!categoryExpanded) { - await this.click(setupWizardAdmin.expandCategories); - } + if (!categoryExpanded) { + await this.click(setupWizardAdmin.expandCategories); + }
90-96: Remove unnecessary empty line and LGTM for the conditional logic.The conditional handling of commission types with appropriate API response waiting is well implemented. However, there's an unnecessary empty line at the start.
await this.goToDokanSettings(); - if (commission.commissionType === 'fixed') {tests/pw/pages/settingsPage.ts (2)
144-145: LGTM! Consider adding error case validations.The commission value validations are correctly implemented using Playwright's
toHaveValueassertions. This ensures the settings are properly persisted after saving.Consider adding validations for error cases, such as:
await expect(async () => { await this.toHaveValue(settingsAdmin.selling.percentage, 'invalid'); }).rejects.toThrow();
Line range hint
1-1000: Consider architectural improvements for better maintainability.The file contains numerous methods with similar patterns for different settings. Consider these improvements:
- Create a generic settings handler:
private async updateSettings<T>( menu: string, settings: T, configure: (settings: T) => Promise<void> ): Promise<void> { await this.goToDokanSettings(); await this.click(settingsAdmin.menus[menu]); await configure(settings); await this.clickAndWaitForResponseAndLoadState(data.subUrls.ajax, settingsAdmin.saveChanges); }
- Use builder pattern for settings:
class SellingSettingsBuilder { private settings: Partial<dokanSettings['selling']> = {}; withCommission(percentage: string, fixed: string) { this.settings.commission = { percentage, fixed }; return this; } build() { return this.settings as dokanSettings['selling']; } }This would make the code more maintainable and reduce duplication.
tests/pw/pages/selectors.ts (1)
695-696: LGTM! Consider documenting the dual selector approach.The added selectors provide flexibility to locate commission fields by category ID, complementing the existing name-based selectors.
Consider adding a comment explaining that commission fields can be located by either category name or ID for better maintainability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
tests/pw/pages/commissionPage.ts(4 hunks)tests/pw/pages/selectors.ts(9 hunks)tests/pw/pages/settingsPage.ts(1 hunks)tests/pw/playwright.config.ts(1 hunks)tests/pw/tests/e2e/commission.spec.ts(3 hunks)tests/pw/utils/testData.ts(8 hunks)
🔇 Additional comments (12)
tests/pw/tests/e2e/commission.spec.ts (3)
44-77: Verify tag changes from @Pro to @lite
The change of tags from @Pro to @lite for commission-related tests suggests these features are now available in the lite version. Please verify:
- That these features are indeed available in the lite version
- That no PRO-specific assertions were removed
Let's verify the feature availability:
#!/bin/bash
# Check for any remaining @pro tags in commission-related tests
rg "@pro.*commission" tests/
# Check for commission-related functions in lite version
rg -A 5 "setCommission" tests/9-9: Review the impact of removing PRO feature tests
The removal of DOKAN_PRO conditional logic and commenting out subscription-related setup could lead to reduced test coverage for PRO features. Consider:
- Maintaining separate test files for PRO features instead of commenting them out
- Using feature flags or configuration to control test execution
Let's verify the test coverage impact:
Also applies to: 25-31
36-39: Ensure cleanup matches setup operations
The cleanup section should mirror the setup section. While basic cleanup is maintained, consider:
- Documenting why PRO-specific cleanup was removed
- Verifying that no remnant data from previous PRO tests could affect subsequent test runs
Let's verify cleanup completeness:
✅ Verification successful
Let me gather more information about the setup section to compare with the cleanup.
Let me try a different approach to check the setup and cleanup patterns.
Let me check one more thing to see the complete setup and cleanup pattern.
Commented PRO-specific cleanup correctly mirrors setup
The cleanup section in afterAll perfectly mirrors the setup in beforeAll. Both sections have the same PRO-specific code commented out, maintaining symmetry:
- Setup: Commented out enabling subscription settings and product creation
- Cleanup: Commented out disabling the same subscription settings
The basic cleanup with setOptionValue for selling settings remains active in both sections, which is correct since it's also active in setup.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any lingering subscription settings that might affect tests
rg -A 5 "vendor_subscription" tests/
Length of output: 7849
Script:
#!/bin/bash
# Check the setup section for vendor subscription settings
rg -B 10 "vendor_subscription" tests/pw/tests/e2e/commission.spec.ts
Length of output: 68
Script:
#!/bin/bash
# Look for setup/beforeAll/beforeEach sections in the test file
rg -B 5 -A 10 "beforeAll|beforeEach" tests/pw/tests/e2e/commission.spec.ts
Length of output: 630
Script:
#!/bin/bash
# Look for afterAll/afterEach sections and their surrounding context
rg -B 10 -A 5 "afterAll|afterEach" tests/pw/tests/e2e/commission.spec.ts
Length of output: 1034
tests/pw/playwright.config.ts (1)
104-104:
Critical: Commenting out authentication may break booking product tests
Removing the Authorization header could prevent tests from accessing authenticated endpoints, which is particularly concerning for booking product tests that typically require authentication. This change appears inconsistent with the PR's objective of adding booking product tests.
Let's verify the authentication requirements:
Consider either:
- Restoring the authentication header
- Implementing an alternative authentication mechanism
- Documenting why authentication is no longer needed for these tests
tests/pw/pages/commissionPage.ts (3)
21-22: LGTM! Clear separation of fixed commission type handling.
The code correctly handles the fixed commission type selection without unnecessary API response waiting.
53-55: Same indentation issue as above.
26-27: LGTM! Proper API response handling for non-fixed commission types.
The code correctly waits for the multistep categories API response when selecting non-fixed commission types.
✅ Verification successful
Let me verify the implementation of selectByValueAndWaitForResponse to ensure proper API response handling.
Let me try a different approach to verify the method implementation.
Proper implementation confirmed for API response handling
The implementation correctly uses selectByValueAndWaitForResponse which ensures synchronization with the API by:
- Waiting for the response from the multistep categories endpoint
- Verifying the response status code (defaults to 200)
- Properly handling the Promise.all for concurrent operations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the API endpoint usage
rg -A 2 "subUrls.api.dokan.multistepCategories" --type ts
Length of output: 628
Script:
#!/bin/bash
# Check the implementation of selectByValueAndWaitForResponse
ast-grep --pattern 'selectByValueAndWaitForResponse($$$) {
$$$
}'
Length of output: 69
Script:
#!/bin/bash
# Search for the method definition using ripgrep
rg -A 10 "selectByValueAndWaitForResponse.*=.*" --type ts
Length of output: 1684
tests/pw/utils/testData.ts (2)
366-411: Well-structured booking configuration!
The booking product configuration has been nicely organized into logical groups (duration, availability, costs, extraOptions), making the code more maintainable and easier to understand.
1154-1154: LGTM: Booking product edit function
The booking product edit function follows the established pattern for product editing URLs and aligns with the PR objectives.
tests/pw/pages/selectors.ts (3)
2075-2076: LGTM! Consistent implementation across sections.
The selectors follow the same pattern as in other sections, maintaining consistency in the codebase.
2631-2632: LGTM! Maintains selector pattern consistency.
The selectors are implemented consistently with other sections, providing the same functionality.
3162-3163: LGTM! Completes the consistent implementation.
The selectors complete the pattern across all relevant sections of the codebase.
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (15)
tests/pw/pages/customerPage.ts (1)
Line range hint
123-126: Consider improving parameter handling in subscription flowWhile the subscription pack handling is well-implemented with proper visibility checks, consider these improvements:
- Extract the payment method as a configurable parameter instead of hardcoding 'bank'
- Use an options object for
placeOrderparameters to improve readabilityExample refactor:
-if (subscriptionPackIsVisible) await this.placeOrder('bank', false, true, false); +const subscriptionPaymentOptions = { + paymentMethod: this.config.defaultSubscriptionPayment || 'bank', + getOrderDetails: false, + billingAddress: true, + shippingAddress: false +}; +if (subscriptionPackIsVisible) await this.placeOrder(subscriptionPaymentOptions);tests/pw/pages/vendorBookingPage.ts (4)
157-173: Consider extracting repeated patterns into helper methodsThe
updateBookingProductFieldsmethod contains repeated patterns for setting booking duration, availability, and costs. Consider extracting these into separate helper methods to improve maintainability and reduce code duplication.- // booking duration options - await this.selectByValue(bookingProductsVendor.booking.bookingDurationType, product.duration.bookingDurationType); - await this.clearAndType(bookingProductsVendor.booking.bookingDurationMin, product.duration.bookingDurationMin); - await this.clearAndType(bookingProductsVendor.booking.bookingDurationMax, product.duration.bookingDurationMax); - await this.selectByValue(bookingProductsVendor.booking.bookingDurationUnit, product.duration.bookingDurationUnit); + await this.setBookingDuration(product.duration);
445-445: Consider creating a helper method for keyboard interactionsMultiple occurrences of
press('Escape')with the same comment suggest this is a common operation. Consider creating a helper method to encapsulate this behavior.+ private async shiftFocusFromElement(): Promise<void> { + await this.press('Escape'); + } - await this.press('Escape'); // shift focus from element + await this.shiftFocusFromElement();Also applies to: 933-933, 939-939, 1005-1005
852-852: Replace TODO comments with proper element identificationThe TODO comments indicate a need to replace element selectors with proper resource IDs. This should be addressed to improve test reliability.
Would you like me to help create a GitHub issue to track the implementation of proper element identification for these selectors?
Also applies to: 883-883
579-580: Address TODO comment about refactoring switch statementsThe TODO comment suggests refactoring switch statements to use object member actions. This would improve code maintainability and reduce duplication.
Consider implementing an object-based approach:
private readonly inventoryActions = { 'sku': { action: async (inventory) => await this.clearAndType(productsVendor.inventory.sku, inventory.sku), assertion: async (inventory) => await this.toHaveValue(productsVendor.inventory.sku, inventory.sku) }, // ... other actions }; async addProductInventory(productName: string, inventory: product['productInfo']['inventory'], choice: string): Promise<void> { await this.goToBookingProductEditById(productName); await this.inventoryActions[choice]?.action(inventory); await this.saveProduct(); await this.inventoryActions[choice]?.assertion(inventory); }tests/pw/feature-map/feature-map.yml (4)
1327-1330: Consider adding validation test cases for basic product management.While the basic CRUD operations are covered, consider adding these test cases:
- Validate empty/invalid title updates
- Verify accommodation booking option constraints
1340-1345: Add media validation test cases.Consider adding these test cases:
- Validate image file types/sizes
- Test gallery image limits
- Verify image order management in gallery
1346-1349: Add HTML content validation test cases.Consider adding test cases to verify:
- HTML content sanitization
- Rich text formatting preservation
1383-1394: Add integration test cases for addon and geolocation features.Consider adding these integration test cases:
- Verify addon pricing calculations in booking cost
- Test geolocation impact on booking availability
- Validate attribute combinations for booking slots
tests/pw/utils/payloads.ts (3)
Line range hint
965-991: LGTM! Consider adding JSDoc comments.The implementation of required fields for bookable products is well-structured. Consider adding JSDoc comments to document the purpose and constraints of each field, especially for fields like
duration_type,duration_unit, andblock_costto help other developers understand their usage./** * Creates required fields for a bookable product * @returns {Object} Object containing minimum required fields * * @field duration_type - Type of duration ('customer' or fixed) * @field duration_unit - Unit of duration (day, hour, minute) * @field block_cost - Cost per block of time * ... */ createBookableProductRequiredFields: () => ({
993-1031: Clarify relationship between cost fieldsThe implementation adds a
display_costfield alongside existingcostandblock_cost. The relationship and purpose of these different cost fields should be clarified:
block_cost: Cost per time blockcost: Base costdisplay_cost: Purpose unclear - is this for display only?Consider adding comments to explain when each cost field is used and how they interact.
1041-1103: Consider flexible check-in/out time configurationThe accommodation booking implementation hardcodes check-in/out times to "12:00 am". Consider:
- Making these times configurable parameters
- Using a proper time format handling library
- Adding validation for valid time ranges
- value: '12:00 am', + value: accommodationConfig.checkInTime || '12:00 pm',tests/pw/pages/selectors.ts (3)
5225-5238: Remove redundant tag locators and commentsThe code contains redundant tag locators and TODO comments that should be cleaned up.
- // todo: remove below lines if the behavior is actually changed - // searchedTag: (tagName: string) => `//li[contains(@class,"select2-results__option") and contains(@id, "select2-product_tag-result") and normalize-space(text())="${tagName}"]`, - // nonCreatedTag: (tagName: string) => `//li[@class="select2-results__option select2-results__option--highlighted" and normalize-space(text())="${tagName}"]`,
Line range hint
1-20: Add comprehensive documentation for the selectors moduleThe file lacks proper documentation explaining its purpose and usage.
Add JSDoc documentation at the top of the file:
/** * @fileoverview Contains all the locators used in Dokan test automation framework * * This module exports a constant object containing locators organized into three main sections: * - Admin: Locators for admin dashboard and functionality * - Vendor: Locators for vendor dashboard and functionality * - Customer: Locators for customer-facing pages and functionality * * @module selectors */
5715-5718: Remove commented out codeThe code contains commented out locators that should be removed if no longer needed.
- // todo: remove below lines if the behavior is actually changed - // searchedTag: (tagName: string) => `//li[contains(@class,"select2-results__option") and contains(@id, "select2-product_tag-result") and normalize-space(text())="${tagName}"]`, - // nonCreatedTag: (tagName: string) => `//li[@class="select2-results__option select2-results__option--highlighted" and normalize-space(text())="${tagName}"]`,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (11)
tests/pw/feature-map/feature-map.yml(1 hunks)tests/pw/pages/customerPage.ts(1 hunks)tests/pw/pages/selectors.ts(8 hunks)tests/pw/pages/vendorAuctionsPage.ts(2 hunks)tests/pw/pages/vendorBookingPage.ts(5 hunks)tests/pw/playwright.config.ts(2 hunks)tests/pw/tests/e2e/productsDetailsAuction.spec.ts(6 hunks)tests/pw/tests/e2e/productsDetailsBookings.spec.ts(1 hunks)tests/pw/utils/interfaces.ts(1 hunks)tests/pw/utils/payloads.ts(4 hunks)tests/pw/utils/testData.ts(8 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- tests/pw/pages/vendorAuctionsPage.ts
- tests/pw/playwright.config.ts
- tests/pw/tests/e2e/productsDetailsAuction.spec.ts
- tests/pw/tests/e2e/productsDetailsBookings.spec.ts
🔇 Additional comments (12)
tests/pw/pages/customerPage.ts (2)
120-122: LGTM: Robust terms and conditions handling
The implementation safely handles terms and conditions by checking visibility before clicking, preventing potential test failures.
Line range hint 120-126: Verify selector definitions and subscription integration
Let's verify the integration points for the new changes.
✅ Verification successful
Based on the results, I can see that all the selectors used in the code are properly defined in tests/pw/pages/selectors.ts. Let me verify the specific test coverage and integration by checking the actual test implementations.
Integration verified - selectors and subscription handling are properly implemented
The verification shows that:
- All selectors (
termsAndConditions,subscriptionPack,becomeAVendor) are properly defined in the selectors file - The subscription pack selection is consistently implemented across vendor registration flows
- The changes align with existing test implementations in both customer and EU compliance test specs
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify selector definitions and subscription integration
# Check if selectors are properly defined
echo "Checking selector definitions..."
rg -A 2 "termsAndConditions|subscriptionPack" tests/pw/pages/selectors.ts
# Check if subscription-related test files exist
echo "Checking subscription test coverage..."
fd -e ts -e js "subscription.*test"
# Check for other vendor registration tests
echo "Checking related test files..."
rg -l "customerBecomeVendor" tests/
Length of output: 1752
Script:
#!/bin/bash
# Check the implementation of customer become vendor tests
echo "Checking customer become vendor test implementations..."
rg -A 5 "customerBecomeVendor|placeOrder.*bank" tests/pw/tests/e2e/customer.spec.ts tests/pw/tests/e2e/euCompliance.spec.ts
# Check for any other usage of subscription pack selection
echo "Checking subscription pack selection usage..."
rg "selectByLabel.*subscriptionPack|dokan-subscription-pack" tests/
Length of output: 2056
tests/pw/utils/interfaces.ts (3)
261-267: Previous review comment is still applicable
A past review comment already suggested improving the types for duration properties.
271-280: Previous review comment is still applicable
A past review comment already suggested improving the types for availability properties.
287-306: Previous review comment is still applicable
A past review comment already suggested improving the types for extra options properties.
tests/pw/pages/vendorBookingPage.ts (1)
972-977:
Add error handling for attribute term addition
The attribute term addition lacks error handling. If the term addition fails, there's no handling of the error case.
if (addTerm) {
+ try {
await this.click(productsVendor.attribute.addNew);
await this.clearAndType(productsVendor.attribute.attributeTermInput, attribute.attributeTerm);
await this.clickAndWaitForResponse(data.subUrls.ajax, productsVendor.attribute.confirmAddAttributeTerm);
await this.toBeVisible(productsVendor.attribute.selectedAttributeTerm(attribute.attributeTerm));
+ } catch (error) {
+ throw new Error(`Failed to add attribute term: ${error.message}`);
+ }
}Likely invalid or redundant comment.
tests/pw/feature-map/feature-map.yml (3)
1331-1339: LGTM! Comprehensive coverage for taxonomy management.
The test coverage for categories and tags is thorough and consistent with other product types.
1350-1367: LGTM! Thorough coverage of product options.
The test coverage for product options is comprehensive and aligns well with other product types.
1327-1394: Add comprehensive error handling test coverage.
While the feature coverage is extensive, consider adding these error handling test cases:
- Network failure scenarios
- Concurrent booking attempts
- Invalid data handling
- Permission boundary tests
tests/pw/utils/testData.ts (2)
366-417: Well-structured booking configuration!
The reorganization of booking-related settings into logical groups (accommodationBookingOptions, duration, availability, costs, extraOptions) improves code maintainability and readability.
617-618: Commission formatting standardization
The locale handling has been standardized to use 'ES' consistently across all commission formatting, addressing the previous TODO comments.
Also applies to: 911-912, 921-922, 929-932, 950-951, 1339-1340, 2180-2181
tests/pw/pages/selectors.ts (1)
Line range hint 1-6500: Verify XPath locator robustness
The code uses many complex XPath locators. Let's verify their robustness by checking for any potential matches in the codebase.
✅ Verification successful
Based on the shell script results, I can verify the XPath locator robustness:
XPath locators are well-structured and robust
- The locators use a good mix of attributes and text matching for uniqueness
- Multiple predicates are used appropriately to narrow down elements
- Contains() is used judiciously for partial text matching
- Text() is used correctly for exact text matching
- The locators follow a consistent pattern and style
- Relative paths are used appropriately with // where needed
- Attributes like @Class, @id, etc. are used effectively for targeting
- Dynamic locators using template literals handle variable text well
The XPath locators demonstrate good practices like:
- Using contains() for dynamic text
- Multiple attribute checks for uniqueness
- Proper axis navigation
- Careful use of predicates
- Consistent structure and style
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential XPath locator matches in the codebase
# Test: Search for XPath locators with multiple predicates to verify uniqueness
rg "//.*\[.*\].*\[.*\]" tests/pw/pages/selectors.ts
# Test: Search for XPath locators using text() to verify text matching
rg "//.*text\(\).*=" tests/pw/pages/selectors.ts
# Test: Search for XPath locators using contains() to verify partial text matching
rg "//.*contains\(.*\).*=" tests/pw/pages/selectors.ts
Length of output: 174914
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
Documentation
Refactor
bookinginterface and related payloads for better modularity.Chores