Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add product form tests #2383

Merged
merged 3 commits into from
Sep 30, 2024

Conversation

shashwatahalder01
Copy link
Contributor

@shashwatahalder01 shashwatahalder01 commented Sep 30, 2024

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

    • Enhanced vendor capabilities across multiple pages, including product management, withdrawal requests, and support ticket management.
    • New functionalities for adding and editing products, including managing pricing and discounts.
    • Introduction of comprehensive end-to-end tests for product details management.
  • Bug Fixes

    • Improved error handling for product creation without required fields.
  • Tests

    • Added new tests for vendor functionalities and product details.
    • Updated existing tests to reflect changes in product management capabilities.

Copy link
Contributor

coderabbitai bot commented Sep 30, 2024

Walkthrough

The pull request introduces significant updates to the feature map configuration and various test files, enhancing vendor capabilities in product management across multiple pages. Key changes include disabling administrative features for the Dokan plugin, enabling vendor functionalities for managing products, and introducing new testing methods for product creation and editing. The updates also enhance the flexibility of test setups and ensure thorough validation of product-related functionalities.

Changes

File Path Change Summary
tests/pw/feature-map/feature-map.yml Updated feature map configuration to restrict Dokan plugin capabilities while enhancing vendor functionalities for Tax, Shipping, Products, Withdraw, Catalog Mode, Store Support, and Vendor Subscription pages.
tests/pw/pages/productsPage.ts Enhanced ProductsPage class with new methods for product management, including adding and editing product attributes, and handling errors when required fields are missing.
tests/pw/tests/api/orderDownloads.spec.ts Added dynamic data import for image paths in tests and maintained structure for validating order downloads API responses.
tests/pw/tests/e2e/products.spec.ts Modified product functionality tests for admin and vendor roles, adding a new test for vendor product addition and marking another as skipped.
tests/pw/tests/e2e/productsDetails.spec.ts Introduced a new suite of end-to-end tests for vendor product details functionality, validating updates to product attributes and discount management.
tests/pw/utils/payloads.ts Added new functions for creating products with comprehensive attributes and discounts, enhancing product creation capabilities.

Possibly related PRs

Suggested labels

QA approved

Suggested reviewers

  • shohag121

Poem

🐇 In fields of code, we hop and play,
With features bright, we pave the way.
Vendors can now create with ease,
Adding products like a gentle breeze.
So let’s rejoice, with carrots in hand,
For changes made, oh so grand! 🌟


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
🪧 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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 12

🧹 Outside diff range and nitpick comments (15)
tests/pw/tests/api/orderDownloads.spec.ts (2)

20-20: Good implementation of the imported test data!

The usage of data.image.avatar in place of a hardcoded image path is well done. It enhances the test's maintainability and reusability.

For even better clarity, consider adding a brief comment explaining what data.image.avatar represents, e.g.:

// Upload a test avatar image for the downloadable product
const [responseBody] = await apiUtils.uploadMedia(data.image.avatar, payloads.mimeTypes.png, payloads.adminAuth);

Line range hint 1-62: Consider enhancing error handling and assertions in the test suite.

The overall structure and implementation of the tests are good. Here are some suggestions to further improve the test suite:

  1. Error Handling: Consider adding try-catch blocks or using test.fail() to handle potential errors more gracefully, especially in the beforeAll hook where multiple async operations are performed.

  2. Specific Assertions: While using schemas for validation is excellent, consider adding more specific assertions for critical fields. For example, in the "get all order downloads" test, you could assert the presence of the newly created download.

  3. Cleanup: Consider adding a test.afterAll hook to clean up created resources (products, orders, downloads) to ensure a clean state for future test runs.

  4. Parameterized Tests: If applicable, consider using test.describe.parallel() and parameterized tests to improve test execution speed and coverage.

Example of a more specific assertion:

test('get all order downloads', { tag: ['@lite', '@v2'] }, async () => {
    const [response, responseBody] = await apiUtils.get(endPoints.getAllOrderDownloads(orderId));
    expect(response.ok()).toBeTruthy();
    expect(responseBody).toBeTruthy();
    expect(responseBody).toMatchSchema(schemas.orderDownloadsSchema.orderDownloadsSchema);
    
    // Add a specific assertion
    expect(responseBody.some(download => download.product_id === downloadableProductId)).toBeTruthy();
});
tests/pw/tests/e2e/products.spec.ts (2)

74-76: LGTM! Consider adding assertions for critical elements.

The new test for verifying that vendors can view the add new product page is a valuable addition. It aligns well with the PR objectives and follows the existing test structure.

To enhance the test's robustness, consider adding specific assertions for critical elements on the add new product page. For example:

test('vendor can view add new product page', { tag: ['@lite', '@vendor'] }, async () => {
    await vendor.vendorAddNewProductRenderProperly();
    // Add assertions for critical elements, e.g.:
    // await expect(page.locator('#product-name')).toBeVisible();
    // await expect(page.locator('#product-type')).toBeVisible();
});

Line range hint 1-174: Overall great job! Consider improving test isolation.

The changes in this file align well with the PR objectives of enhancing product form testing. The tests are well-organized, properly tagged, and cover a wide range of scenarios for both admin and vendor roles.

To further improve the test suite, consider enhancing test isolation:

  1. Use test.describe.configure({ mode: 'parallel' }) at the top of the file to enable parallel test execution if not already implemented elsewhere.
  2. Instead of creating products in beforeAll, consider creating them in individual tests or in test.beforeEach() hooks for better isolation.
  3. Ensure each test cleans up its own data to prevent interdependencies between tests.

Example:

test.describe.configure({ mode: 'parallel' });

test.describe('Product functionality test', () => {
    // ... existing setup ...

    test.beforeEach(async ({ browser }) => {
        // Setup for each test
    });

    test.afterEach(async () => {
        // Cleanup after each test
    });

    // ... existing tests ...
});

These changes can improve test reliability and make it easier to run tests in parallel, potentially reducing overall execution time.

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

Line range hint 320-321: Improved vendor control over reverse withdrawals.

The new features added to the "Reverse Withdrawal" page for vendors are beneficial:

  1. Vendors can now filter reverse withdrawals by date, improving their ability to track and manage these transactions.
  2. The ability to pay reverse withdrawal balance gives vendors more control over their financial operations.

These additions enhance the vendor's financial management capabilities within the platform.

Consider adding a feature for vendors to export filtered reverse withdrawal data for better record-keeping and financial reporting. This could be implemented as follows:

vendor can filter reverse withdrawals by date [lite]: true
vendor can pay reverse withdrawal balance [lite]: true
+ vendor can export filtered reverse withdrawal data [lite]: true

Line range hint 328-335: Valuable addition of catalog mode functionality.

The new features in the "Catalog Mode" section provide important capabilities:

  1. Admins and vendors can set catalog mode, giving them control over how products are displayed.
  2. Options to disable hiding product prices in catalog mode for both admins and vendors.
  3. Vendors can set catalog mode at both store-wide and single product levels.
  4. Customers can view products in catalog mode.

These features offer flexibility in product presentation, which can be beneficial for various business strategies.

To enhance this feature, consider adding an option for admins to set default catalog mode behavior that vendors can then override. This could be implemented as:

admin can set catalog mode [lite]: true
admin can disable hide product price in catalog mode [lite]: true
+ admin can set default catalog mode behavior [lite]: true
vendor can set catalog mode (storewide) [lite]: true
vendor can set catalog mode (single product) [lite]: true
vendor can disable hide product price in catalog mode [lite]: true
+ vendor can override default catalog mode behavior [lite]: true

Line range hint 1003-1004: Enhanced vendor subscription options with non-recurring packs.

The addition of non-recurring subscription pack purchase options for vendors is a positive change:

  1. Vendors can now buy non-recurring subscription packs during registration.
  2. Vendors can also purchase these packs on the subscription page.

These features provide flexibility for vendors in choosing and managing their subscription status.

While the addition of non-recurring subscription packs is valuable, consider implementing recurring subscription options in the future for vendors who prefer automatic renewals. This could be done by changing the following lines:

vendor can buy recurring subscription pack (on registration): false
vendor can buy recurring subscription pack (on subscription page): false
+ vendor can buy recurring subscription pack (on registration): true
+ vendor can buy recurring subscription pack (on subscription page): true

Additionally, you might want to add an option for vendors to switch between recurring and non-recurring subscription types:

vendor can switch subscription: true
+ vendor can switch between recurring and non-recurring subscriptions: true

Line range hint 1-1089: Overall positive enhancements to vendor capabilities and platform flexibility.

This update to the feature map configuration file brings several valuable improvements to the Dokan platform:

  1. Significantly enhanced product management capabilities for vendors.
  2. Improved financial control for vendors through reverse withdrawal features.
  3. Introduction of catalog mode functionality, offering more flexibility in product display.
  4. Addition of non-recurring subscription options for vendors.

These changes align well with the PR objective of enhancing product form functionality and generally improve the vendor experience on the platform. The updates provide more control and flexibility to vendors in managing their products, finances, and subscriptions.

As the platform continues to evolve, consider the following architectural suggestions:

  1. Implement a modular approach to feature additions, allowing for easier enabling/disabling of specific capabilities.
  2. Consider creating a vendor settings API that can be easily extended as new features are added.
  3. Ensure that new features are consistently implemented across different areas of the platform (e.g., subscription management, product management) to maintain a cohesive user experience.
  4. As the feature set grows, consider implementing feature flags for gradual rollout and A/B testing of new capabilities.
tests/pw/tests/e2e/productsDetails.spec.ts (3)

9-9: Remove unused import 'serialize' from 'php-serialize'

The imported function serialize from 'php-serialize' is not used anywhere in the code and can be safely removed to clean up the imports.

Apply this diff to remove the unused import:

- import { serialize } from 'php-serialize';

11-11: Remove unused constant 'CATEGORY_ID'

The constant CATEGORY_ID is imported from process.env but is not used in the code. It can be safely removed to tidy up the code.

Apply this diff to remove the unused constant:

- const { CATEGORY_ID } = process.env;

31-32: Resolve TODO or remove commented-out code

There are commented-out lines with a TODO comment indicating that mediaUrl is not working on GitHub Actions. Leaving commented-out code can clutter the codebase. Consider resolving the issue with mediaUrl or remove the commented-out code if it's no longer needed.

tests/pw/pages/productsPage.ts (4)

374-375: Avoid Potential Confusion with Variable Name length

At line 374, you're destructuring length from productsVendor.rma. Since length is commonly associated with arrays and strings, using it as a variable name could cause confusion. Consider renaming it to something more descriptive, such as rmaLength or durationLength.


388-391: Address TODO Comment Regarding EU Compliance Fields

There is a TODO comment about checking for the Germanized plugin, and the code related to EU compliance fields is commented out. Please implement the necessary checks or remove the commented code if it's no longer needed.

Would you like assistance in implementing this functionality or creating a GitHub issue to track this task?


668-668: Typo in Error Message Verification

The error message 'Error! Description is a required field..' contains an extra period at the end. Verify if this matches the actual error message displayed by the application. If it's a typo, update it to 'Error! Description is a required field.'.


779-779: Address TODO Comment for Additional Assertions

At line 779, there's a TODO comment: // todo: add more assertions to all product edit test, customer pov. Enhancing your tests with additional assertions from the customer's point of view will improve test coverage and reliability.

Would you like help drafting these additional assertions, or should we open a GitHub issue to track this enhancement?

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 9754f7e and 4b47bfa.

📒 Files selected for processing (6)
  • tests/pw/feature-map/feature-map.yml (2 hunks)
  • tests/pw/pages/productsPage.ts (3 hunks)
  • tests/pw/tests/api/orderDownloads.spec.ts (2 hunks)
  • tests/pw/tests/e2e/products.spec.ts (3 hunks)
  • tests/pw/tests/e2e/productsDetails.spec.ts (1 hunks)
  • tests/pw/utils/payloads.ts (2 hunks)
🔇 Additional comments (5)
tests/pw/tests/api/orderDownloads.spec.ts (1)

10-10: Excellent use of centralized test data!

The addition of import { data } from '@utils/testData'; is a positive change. It improves the test's flexibility by using a dynamic data source instead of a hardcoded image path. This follows the best practice of centralizing test data, making it easier to maintain and update across multiple tests.

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

161-163: Implement or provide context for the skipped test.

A new test has been added to verify that vendors cannot add products without required fields, but it's currently skipped.

Could you please provide context on why this test is skipped? If it's due to pending implementation:

  1. Consider adding a TODO comment explaining the reason and any blockers.
  2. If possible, implement the test to enhance coverage of edge cases.

Here's a suggestion for implementing the test:

test("vendor can't add product without required fields", { tag: ['@lite', '@vendor'] }, async () => {
    await vendor.addProductWithoutRequiredFields(data.product.simple);
    // Add assertions to verify the product wasn't added and error messages are displayed
    // await expect(page.locator('.error-message')).toBeVisible();
    // await expect(page.locator('.error-message')).toContainText('Required fields are missing');
});

If there are known issues preventing the implementation, please add a comment explaining the situation.


28-28: Verify the intention behind commenting out product deletion.

The line for deleting all products in the afterAll hook has been commented out. This could potentially lead to test data pollution between test runs.

Could you please clarify the reasoning behind this change? If it's intentional, consider adding a comment explaining why product deletion is skipped. If it's unintentional, please uncomment the line to ensure proper cleanup after tests.

To verify the impact, you can run the following script:

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

Line range hint 94-129: Excellent enhancement of vendor product management capabilities!

The new features added to the "Products" page for vendors significantly improve their ability to manage products effectively. These additions cover a wide range of functionalities, including:

  1. Adding various product types (simple, variable, subscription, external, group, downloadable, virtual)
  2. Advanced product filtering and searching
  3. Import/export capabilities
  4. Duplicate product functionality
  5. Detailed product management (title, permalink, pricing, discounts)

These enhancements align well with the PR objective of improving product form functionality and will greatly benefit vendors using the Dokan platform.

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

665-665: Verify Error Message Selector and Text

At line 665, you're asserting on productsVendor.NoTitleError for the error message 'This field is required'. Ensure that NoTitleError is the correct selector and matches the application's actual DOM structure. Additionally, confirm that the error message text is accurate.

tests/pw/tests/e2e/productsDetails.spec.ts Show resolved Hide resolved
tests/pw/tests/e2e/productsDetails.spec.ts Show resolved Hide resolved
tests/pw/tests/e2e/productsDetails.spec.ts Show resolved Hide resolved
tests/pw/tests/e2e/productsDetails.spec.ts Show resolved Hide resolved
tests/pw/tests/e2e/productsDetails.spec.ts Show resolved Hide resolved
tests/pw/utils/payloads.ts Show resolved Hide resolved
tests/pw/utils/payloads.ts Show resolved Hide resolved
tests/pw/utils/payloads.ts Show resolved Hide resolved
tests/pw/utils/payloads.ts Show resolved Hide resolved
tests/pw/utils/payloads.ts Show resolved Hide resolved
@shashwatahalder01 shashwatahalder01 added the QA approved This PR is approved by the QA team label Sep 30, 2024
@shashwatahalder01 shashwatahalder01 merged commit 2feb1d8 into getdokan:develop Sep 30, 2024
2 checks passed
@coderabbitai coderabbitai bot mentioned this pull request Oct 1, 2024
12 tasks
@shashwatahalder01 shashwatahalder01 deleted the liteProductEdit branch October 1, 2024 06:49
@coderabbitai coderabbitai bot mentioned this pull request Nov 1, 2024
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QA approved This PR is approved by the QA team Test Automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant