Auction tests

[shashwatahalder01]

All Submissions:

• My code follow the WordPress' coding standards
• My code satisfies feature requirements
• My code is tested
• My code passes the PHPCS tests
• My code has proper inline documentation
• I've included related pull request(s) (optional)
• I've included developer documentation (optional)
• I've added proper labels to this pull request

Changes proposed in this Pull Request:

Related Pull Request(s)

• Full PR Link

Closes

• Closes #

How to test the changes in this Pull Request:

• Steps or issue link

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:

• Code is not following code style guidelines
• Bad naming: make sure you would understand your code if you read it a few months from now.
• KISS: Keep it simple, Sweetie (not stupid!).
• DRY: Don't Repeat Yourself.
• Code that is not readable: too many nested 'if's are a bad sign.
• Performance issues
• Complicated constructions that need refactoring or comments: code should almost always be self-explanatory.
• Grammar errors.

FOR PR REVIEWER ONLY:

As a reviewer, your feedback should be focused on the idea, not the person. Seek to understand, be respectful, and focus on constructive dialog.

As a contributor, your responsibility is to learn from suggestions and iterate your pull request should it be needed based on feedback. Seek to collaborate and produce the best possible contribution to the greater whole.

• Correct — Does the change do what it’s supposed to? ie: code 100% fulfilling the requirements?
• Secure — Would a nefarious party find some way to exploit this change? ie: everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities?
• Readable — Will your future self be able to understand this change months down the road?
• Elegant — Does the change fit aesthetically within the overall style and architecture?

Summary by CodeRabbit

• New Features

  • Vendors can now duplicate auction products.
  • Expanded vendor capabilities on the "Delivery Time" page, including changing view styles and filtering.
  • Admins can perform bulk actions on subscribed vendors.
  • Vendors can now close and reopen support tickets with chat replies.
  • Vendors can add and update EU compliance data during registration and checkout.

• Bug Fixes

  • Adjusted permissions to ensure proper functionality for vendors and admins across various pages.

• Tests

  • Added tests for the new auction product duplication feature.
  • Updated existing tests for improved reliability.

[coderabbitai]

Walkthrough

The changes in this pull request primarily involve updates to permissions and functionalities for vendors across various pages, as defined in the feature-map.yml file. Key modifications include enabling vendors to duplicate auction products, manage delivery times, and perform actions related to subscriptions and support tickets. Additionally, new selectors for product duplication and a corresponding method in the AuctionsPage class have been introduced. The test suite has also been updated to include tests for the new duplication functionality while adjusting existing tests for reliability.

Changes

File Path	Change Summary
tests/pw/feature-map/feature-map.yml	Updated vendor permissions for auction duplication, delivery time management, subscription actions, support ticket handling, and EU compliance data.
tests/pw/pages/selectors.ts	Added new selector for product duplication and a success message for duplication confirmation.
tests/pw/pages/vendorAuctionsPage.ts	Introduced duplicateAuctionProduct method to allow duplication of auction products.
tests/pw/tests/e2e/commission.spec.ts	Removed DOKAN_PRO variable and commented out related tests; several tests marked as skipped.
tests/pw/tests/e2e/vendorAuction.spec.ts	Added test for vendor duplicating auction products; modified test for deleting auction products to ensure fresh product creation.

Possibly related PRs

• Add product form tests #2383: Updates to the feature map configuration for vendor capabilities, particularly in the "Products" page.
• Add product categories & tags tests  #2384: Enhancements to vendor capabilities, including management of product categories and tags.
• Add: add product form tests (gallery, description) #2385: Tests for product form functionalities, including vendor capabilities enhanced in the main PR.
• Add: add product form tests (download options, inventory)  #2389: Tests for product downloadable options and inventory management, relevant to vendor capabilities.
• Add: product form tests (other options, catalog) #2391: Tests for additional product options related to vendor functionalities.
• Add: add product form tests( shipping, tax, linked products) #2393: Tests for managing product options, aligning with vendor capabilities enhancements.
• Add: add product form test(attribute, bulk discount, geolocation) #2395: Tests for product attributes and bulk discounts, relevant to vendor functionalities.
• Add: add product tests (product addon, rma) #2396: Tests for product addons and RMA options, related to vendor capabilities.
• Add: add product form tests (wholesale, min-max) #2397: Tests for wholesale and min-max options, relevant to vendor functionalities.
• Add shipstation tests #2444: Tests for ShipStation functionality, related to vendor capabilities.
• Add Geolocation tests #2445: Tests for geolocation functionality, relevant to vendor capabilities.

Suggested labels

QA approved

Suggested reviewers

• mrabbani

🐰 "In fields of code, we hop and play,
With vendor powers growing day by day.
From auctions to support, we leap with glee,
Duplicating products, oh what fun to see!
With tests in place, our features shine bright,
In this coding garden, all feels just right!" 🌼

---

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?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

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)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (8)

tests/pw/tests/e2e/vendorAuction.spec.ts (2)

Line range hint 15-29: Improve test isolation by reducing shared state

The beforeAll hook creates shared state that could lead to test interdependencies:

1. The shared auctionProductName could cause flaky tests if modified
2. The customer.bidAuctionProduct call might not be relevant for all tests

Consider moving product creation and bidding to individual tests where needed:

 test.beforeAll(async ({ browser }) => {
     const adminContext = await browser.newContext(data.auth.adminAuth);
     aPage = await adminContext.newPage();
     admin = new AuctionsPage(aPage);

     const vendorContext = await browser.newContext(data.auth.vendorAuth);
     vPage = await vendorContext.newPage();
     vendor = new AuctionsPage(vPage);

     const customerContext = await browser.newContext(data.auth.customerAuth);
     cPage = await customerContext.newPage();
     customer = new AuctionsPage(cPage);

     apiUtils = new ApiUtils(await request.newContext());
-    [, , auctionProductName] = await apiUtils.createProduct(payloads.createAuctionProduct(), payloads.vendorAuth);
-    await customer.bidAuctionProduct(auctionProductName);
 });

---

Line range hint 93-98: Track the skipped "buy it now" test issue

The skipped test indicates a limitation in the API that should be tracked and addressed.

Would you like me to create a GitHub issue to track the API limitation for saving "buy it now" price? The issue would include:

• Description of the current limitation
• Impact on testing coverage
• Proposed solution for the API

tests/pw/tests/e2e/commission.spec.ts (3)

9-9: Consider using a centralized test configuration

Instead of directly accessing process.env, consider moving all test configuration including PRODUCT_ID to a dedicated config file. This would make test configuration more maintainable and easier to track.

-const { PRODUCT_ID } = process.env;
+import { testConfig } from '@utils/testConfig';
+const { PRODUCT_ID } = testConfig;

---

Line range hint 85-98: Implement missing subscription product creation functionality

The subscription product tests are skipped due to missing createDokanSubscriptionProduct function. This significantly reduces test coverage for subscription-related features.

Would you like me to help create the missing createDokanSubscriptionProduct function implementation?

---

Line range hint 108-109: Create tickets for missing test scenarios

The TODO comments indicate several untested commission-related scenarios for both admin and vendor perspectives. These are critical paths that should be tested:

• Commission visibility in product list
• Commission visibility in order list
• Commission visibility in order details
• Sub-order commission details
• Vendor earning visibility

Would you like me to help create GitHub issues to track these missing test scenarios?

tests/pw/pages/vendorAuctionsPage.ts (2)

154-156: Consider extracting row actions visibility logic to a shared helper method.

The pattern of removing the class attribute to handle row actions visibility is repeated across multiple methods. Consider extracting this to a shared helper method like ensureRowActionsVisible(productName: string) to improve maintainability.

+  private async ensureRowActionsVisible(productName: string): Promise<void> {
+    await this.removeAttribute(auctionProductsVendor.rowActions(productName), 'class');
+    await this.hover(auctionProductsVendor.productCell(productName));
+  }

   async duplicateAuctionProduct(productName: string) {
     await this.searchAuctionProduct(productName);
-    await this.removeAttribute(auctionProductsVendor.rowActions(productName), 'class');
-    await this.hover(auctionProductsVendor.productCell(productName));
+    await this.ensureRowActionsVisible(productName);
     await this.clickAndWaitForResponseAndLoadState(data.subUrls.frontend.vDashboard.auction, auctionProductsVendor.duplicate(productName), 302);
     await this.toBeVisible(auctionProductsVendor.duplicateSuccessMessage);
     await this.toBeVisible(auctionProductsVendor.productCell(productName + ' (Copy)'));
   }

---

152-152: Add JSDoc documentation for the new method.

Consider adding JSDoc documentation to improve code maintainability and IDE support:

+  /**
+   * Duplicates an auction product and verifies the operation's success.
+   * @param productName - The name of the product to duplicate
+   * @throws Will throw an error if the product is not found or duplication fails
+   */
   async duplicateAuctionProduct(productName: string) {

tests/pw/pages/selectors.ts (1)

5711-5712: LGTM with a minor suggestion for the success message selector.

The selectors for auction product duplication functionality look good and follow the existing patterns. However, consider making the success message selector more specific to avoid potential conflicts.

Consider updating the success message selector to be more specific:

-            duplicateSuccessMessage: '//div[contains(@class,"dokan-alert dokan-alert-success")]//strong[normalize-space(text())="Product successfully duplicated"]',
+            duplicateSuccessMessage: '//div[contains(@class,"dokan-alert dokan-alert-success") and contains(.,"Product successfully duplicated")]//strong[normalize-space(text())="Product successfully duplicated"]',

This makes the selector more robust by checking both the container class and message content.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 9b8e9c2 and 58aebbc.

📒 Files selected for processing (5)

• tests/pw/feature-map/feature-map.yml (2 hunks)
• tests/pw/pages/selectors.ts (1 hunks)
• tests/pw/pages/vendorAuctionsPage.ts (1 hunks)
• tests/pw/tests/e2e/commission.spec.ts (4 hunks)
• tests/pw/tests/e2e/vendorAuction.spec.ts (1 hunks)

🔇 Additional comments (5)

tests/pw/tests/e2e/commission.spec.ts (2)

Line range hint 27-31: Remove or refactor commented code blocks

The commented code related to DOKAN_PRO functionality should either be:

1. Removed if the functionality is no longer needed
2. Refactored into a proper conditional implementation
3. Moved to a separate test file for pro features

This will improve code maintainability and prevent confusion.

Also applies to: 39-42

---

52-54: ⚠️ Potential issue

Address systematically skipped category-based commission tests

Multiple category-based commission tests are skipped across different contexts (setup wizard, selling settings, vendor). This suggests a potential issue with the category-based commission feature implementation.

Please clarify:

1. Are these tests temporarily skipped due to known issues?
2. Is the category-based commission feature fully implemented?

Also applies to: 64-66, 76-78

✅ Verification successful

Let me try a different approach to gather more context about the category-based commission tests and implementation.

---

Based on the search results, I can see that the category-based commission feature is fully implemented across the codebase with:

1. Frontend components (Vue.js):

   • CategoryBasedCommission.vue component
   • Commission settings in admin and setup wizard
   • Category commission fields and validation

2. Backend implementation (PHP):

   • Commission strategies including CategoryBased class
   • Commission settings and models
   • Category commission calculations and upgrades

3. Tests:

   • Unit tests for category commission functionality
   • E2E tests for category commission setup

The skipped tests appear to be temporary while verifying the implementation works correctly, rather than indicating missing functionality.

Tests can be unskipped after verifying category commission setup works as expected

The category-based commission feature is fully implemented but the tests are temporarily skipped to validate the implementation. You can unskip these tests once you've manually verified that:

1. Category commission setup works correctly in the Dokan setup wizard
2. Commission calculations are accurate for category-based rules
3. Changes are properly saved and applied

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for category-based commission implementation
ast-grep --pattern 'specificCategory' 

Length of output: 37

---

Script:

#!/bin/bash
# Search for category-based commission related tests and implementation
rg -i "category.*commission" -A 3

# Also check for specific test files related to commission
fd "commission.*\.(ts|js|php)" --exec cat {}

Length of output: 131124

tests/pw/pages/vendorAuctionsPage.ts (1)

152-160: LGTM! The implementation follows best practices.

The method is well-structured and includes proper verification steps:

1. Searches for the product
2. Handles potential UI flakiness
3. Waits for response and verifies success
4. Confirms the duplicated product exists

tests/pw/feature-map/feature-map.yml (2)

687-687: LGTM: Vendor permission for auction product duplication.

The permission flag is correctly configured to allow vendors to duplicate auction products.

---

763-784: ⚠️ Potential issue

Review admin and vendor permission alignment.

There appears to be an inconsistency in the permission structure:

• Admin permissions (lines 763-771) are all set to false
• Vendor permissions have mixed values with some set to true (lines 775-776)

This could create functionality gaps where vendors have permissions that admins don't have. Consider aligning the admin permissions with the vendor permissions.

[coderabbitai]

🛠️ Refactor suggestion

Enhance test verification and cleanup

The test should verify the duplicated product's existence and properties, and ensure proper cleanup. Consider:

1. Verifying the duplicated product's attributes match the original
2. Adding cleanup for both original and duplicated products

 test('vendor can duplicate auction product', { tag: ['@pro', '@vendor'] }, async () => {
     const [, , auctionProductName] = await apiUtils.createProduct(payloads.createAuctionProduct(), payloads.vendorAuth);
-    await vendor.duplicateAuctionProduct(auctionProductName);
+    const duplicatedProductName = await vendor.duplicateAuctionProduct(auctionProductName);
+    // Verify the duplicated product
+    await vendor.verifyDuplicatedProduct(auctionProductName, duplicatedProductName);
+    // Cleanup
+    await apiUtils.deleteProduct(duplicatedProductName, payloads.vendorAuth);
+    await apiUtils.deleteProduct(auctionProductName, payloads.vendorAuth);
 });

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (2)

tests/pw/pages/commissionPage.ts (2)

33-44: Extract wait logic into a reusable method

Multiple instances of fixed waits after form interactions indicate a systemic timing issue.

Consider creating a helper method to handle form interactions consistently:

private async setCommissionValue(selector: string, value: string) {
  await this.clearAndType(selector, value);
  await this.page.waitForFunction(
    ([sel, val]) => {
      const input = document.querySelector(sel) as HTMLInputElement;
      return input && input.value === val;
    },
    [selector, value]
  );
}

This would replace the current pattern:

-await this.clearAndType(setupWizardAdmin.categoryPercentage(...), commission.commissionPercentage);
-await this.wait(1);
+await this.setCommissionValue(setupWizardAdmin.categoryPercentage(...), commission.commissionPercentage);

---

Line range hint 1-190: Consider implementing a robust test infrastructure

The multiple timing adjustments throughout the file suggest a need for a more systematic approach to handling asynchronous operations in tests.

Consider implementing:

1. A custom test fixture that provides standardized waiting and interaction methods
2. Page object methods that encapsulate common patterns of form interaction
3. Utility functions for handling common timing patterns
4. Logging and debugging helpers to identify timing issues

This would help:

• Reduce test flakiness
• Improve maintenance
• Make tests more reliable and faster
• Provide better debugging information

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 58aebbc and 461415a.

📒 Files selected for processing (3)

• tests/pw/pages/commissionPage.ts (3 hunks)
• tests/pw/pages/selectors.ts (2 hunks)
• tests/pw/tests/e2e/commission.spec.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• tests/pw/pages/selectors.ts
• tests/pw/tests/e2e/commission.spec.ts

🔇 Additional comments (1)

tests/pw/pages/commissionPage.ts (1)

127-127: LGTM! Good improvement in navigation reliability

Switching to gotoUntilNetworkidle ensures the page is fully loaded before proceeding with interactions, which is a more reliable approach than simple navigation.

Also applies to: 144-144