4. Test cases

How can I test a translation?

If the PR you are testing is adding a translation, you won’t be able to see the text in another language than English, because the text is not translated on Transifex yet. If the English text remains the same as in production, and the pages do not appear broken it means that it works correctly :-)

As to the translation itself, this can only be checked after the transifex PR has been merged, and deployed in production. Note that adding a translation key won’t necessarily make a translation visible, as only languages translated 100% will be visible in production.

More on https://docs.transifex.com/live/publishing-translations

Bulk Order Management

  1. Go on /shops

  2. Make several order for an ongoing OC, but for the same product

  3. Login with super admin (and/or the producer / shop where you put the orders)

  4. Go to /admin/orders/bulk_management

  5. Are you able to change weight and was the order total recalculated accordingly?

  6. Are you able to change quantity and was the order total recalculated accordingly ?

  7. Are you able to cancel an order ?

  8. Are you able to add columns ?

  9. Are you able to search for a product?

  10. Are you able to change the dates and see results accordingly?

Checkout

  1. Start preferably on desktop using Chrome for Windows (Number 1 use case) :

  2. Go on /shops

  3. Select an open shop and add item to the cart

  4. Press continue

  5. See your cart, but go back “continue shopping” in order to add another product

  6. Press continue

  7. Delete one of the first product you’ve added on the cart and change the quantity on another one

  8. Proceed to checkout, and login

  9. Select delivery and cash payment option

  10. Check you get a confirmation and a confirmation email

  11. Check your order is appearing correctly in /admin/orders

  12. Repeat all these steps on mobile using Firefox as a guest. Ideally both on Android and iOS, but you can also ask for someone else to test a particular device. When filling your profile, try to leave some fields empty to see if errors are correctly displayed.

  13. Repeat those steps for Stripe and Paypal (see how to test payment on OFN if it’s your first time)

Embedded shops

Use these pages in global WP to test:

https://openfoodnetwork.org/user-guide/advanced-features/demo-embedded-shop/

https://openfoodnetwork.org/user-guide/advanced-features/demo-embedded-group/

Enterprise fees

General test

  • enterprise fees

    • add fee to order cycle and see the correct adjustment in the order

  • shop front list of products with correct enterprise fees

  1. create an order with OC fees in an OC

  2. remove product from OC

  3. edit order and recalculate fees. It should be correct.

Then same as above but for closed order cycles:

  1. create order with OC fees

  2. close the OC

  3. edit order and recalculate fees. It should be correct.

Complementary test

As customer:

  1. Make an order selecting the payment method earlier.

  2. Check that the transaction fee is correct.

As enterprise manager:

  1. Create an order selecting the payment method earlier.

  2. Complete the order without capturing payment. Check that the transaction fee is correct.

  3. Capture payment. Check that the transaction fee is still correct.

  4. Create another order.

  5. Complete the order without capturing payment.

  6. Mark the uncaptured payment void. This should not fail.

  7. Add another payment to the order. This should not fail.

  8. Capture payment. Check that the transaction fee is still correct.

Enterprise fee report

Preparations for Testing

For each of these tests, it would be convenient to create a new user with a unique name, to more easily see results in the report.

As superadmin:

  1. Configure the hub to allow pick-up shipping method, with no shipping fee.

  2. Create a payment method with "Bogus" as provider. Set a non-zero fee for this.

  3. Configure the hub to allow both cheque payment and payment through Bogus in Step

A sample card number that works with this test provider is `4111111111111111`. A sample invalid card number is `1111111111111111`. More info here: http://docs.solidus.io/Spree/PaymentMethod/BogusCreditCard.html

Test $0 adjustment is not included

  1. Check out with pick-up for shipping alnd cheque for payment.

  2. There should be no shipping adjustment for the customer in the report.

Check failed/invalid adjustment is not included

  1. Attempt an invalid checkout using Bogus payment method.

  2. There would be no payment adjustment for the customer in the report yet.

  3. Complete the checkout with a valid card number for Bogus again.

  4. There would be an entry for the payment transaction under the customer. The amount should be correct, not double.

Sanity check

  1. Check that HTML and CSV report generation work. These are using the same data objects, so except occasionally, for Steps 2 and 3 there is no need to check results for both formats - just checking one should be sufficient.

  2. Check that the "Enterprise Fee Summary" link is available in the Reports page

  3. For each user role listed above, check that these data are properly summarized: a. Coordinator fee for order cycle b. Coordinator fee for incoming exchange c. Coordinator fee for outgoing exchange d. Producer fee for incoming exchange e. Distributor fee for outgoing exchange f. Shipping fee g. Payment method fee

  4. Do a smoke test that the correct filter options are available to each user role.

  5. Check that orders for orders cycles to which their enterprise is not participant are not available to the user.

  6. Test that using each filter field works. (No need to do this for each user role.)

Login

Multiple languages :

  1. Check that the language selector is showing all available languages both on mobile and desktop

  2. Select a language and see if it’s working on several pages of the shopfront

Product & inventory import

For large files:

  1. Prepare a CSV file with more than 120 lines.

  2. (For Chrome) Open the Network panel of Developer Tools. Filter results to _data: We want to see requests for validate_data and save_data.

  3. Upload the file.

  4. When the file is being validated, there should be 3 HTTP requests for validate_data that are not simultaneous but happen one at a time.

  5. When the file is being saved, there should be 3 HTTP requests for save_data that happen also one at a time.

  6. Test a random row from each batch of 50. The row should have been processed successfully.

  7. Introduce an invalid row to each batch, and upload the file.

  8. The validation errors for each of these invalid rows should show.

For product import :

With :

Apples 1kg

Apples 2kg

Pears

Apples 3 kg

You should get these results:

Apples 1kg -> new product

Apples 2kg -> new variant of new product above

Pears -> new product

Apples 3kg -> new variant of new product above (not a new product!)

For inventory import:

For the "on_demand" column:

  1. If blank - Read as "Use producer stock settings", so "on_hand" should be blank.

  2. If "true", "TRUE", or "1" - Read as on demand of "Yes", so "on_hand" should be blank.

  3. If "false", "FALSE", or "0" - Read as on demand of "No", so "on_hand" is required.

BUT if you use any unsupported string, it will be considered as on demand of "No" (Scenario 3). So, if you use the text "no", it still works _but only by accident_. If you use "yes" which is also unsupported, the result is not what you would expect: it will ask for an "on_hand" value even if you wanted to set unlimited stock. This can indeed be confusing for users, we use "Yes" and "No" in the inventory page...

Also noting another detail: If there is an "on_hand" value, on demand is set to "No" automatically if there is no "on_demand" column. However, if there is an "on_demand" column, the column has to be set to "false"/"FALSE"/"0" to be valid.

  • `on_demand` can be set to "true", "false", or blank

  • If it's set to "true", `on_hand` must be blank.

  • If it's set to "false", `on_hand` must be filled in.

  • If it's left blank, `on_hand` must be blank.

Subscriptions

Manual Testing

Set up the following:

  1. Product for which the shop is the supplier

  2. Product with permitted supplier - Have the supplier grant "add to order cycle" permission to the shop.

  3. Product in an outgoing exchange for a completed OC of the shop

  4. Product in an outgoing exchange for a currently open OC of the shop

  5. Product in an outgoing exchange for a future OC of the shop

  6. Unrelated product

Then, to test:

  1. Create a subscription for the customer.

  2. Without saving the subscription, attempt to add Products 1 to 6 above. It should not be possible to add Product 6.

  3. For Products 1 to 3, there should be a warning: "There are no open or upcoming order cycles for this product."

  4. Save the subscription. This should be successful.

  5. Edit the subscription. In the review page, Products 1 to 3 should have warning: "Unavailable"

  6. Click to edit products in the subscription. There should still be warnings for Products 1 to 3.

  7. Change the start date of the subscription. Saving should be successful.

Testing subscriptions with the rails console

This procedure makes testing easier and much faster, when different conditions should be probed:

Stripe SCA and Stripe Connect (work in progress)

Tag Rules - Overview

To test tags, set up different tags for default rules:

  • Show or Hide variants in my shopfront

  • Show or Hide shipping methods at checkout

  • Show or Hide payment methods at checkout

  • Show or Hide order cycles in my shopfront

Apply the defined tags in the respective feature, and check in whether these are taking effect in the shopfront/checkout.

Next, add exception rules, to specific customers:

  • Show or Hide variants in my shopfront

  • Show or Hide shipping methods at checkout

  • Show or Hide payment methods at checkout

  • Show or Hide order cycles in my shopfront

Apply the defined tags in the specific customers and verify in whether these are taking effect in the shopfront/checkout. Make sure these exception rules override the default rules.

Tag Rules - Sanity check

Use Case: showing/hiding variants from specific customer groups

The following steps test the ability to use tags to show/hide certain variants to different customer types, and serve as a good sanity-check of tag functionality. It will focus on three different customer types (based on a real use-case):

  • Pro customer (Pro)

  • Registered Customer (Reg)

  • Guest customer

We will set up three different variant types for this test - Variants PRO, PART and GRPM:

  • Variant Pro - should only be seen by Pro customers

  • Variants Part and Grpm - Guest customers should see them both; certain registered customers should see only one of them

Setup

To perform these tests we will need to set the following:

  • Create three product variants, named as above (the pics below will follow these designations). Make sure to add these to your inventory

  • Create two registered customers or choose two customers from the available customer list - these will be Pro and Reg)

Before proceeding, make sure the three variants are visible in your shopfront (they have been added to an open-OC with shipping/payment methods) to all three customer types.

Test 1 - hide PRO variant from everyone

  • Go to the Tags sub-menu, on the Dashboard of your enterprise.

  • Add a default rule, as shown below:

  • Go to your Inventory and add the pro tag to the chosen variant.

Pass criteria: Pro variant should now be invisible to all users.

tag_1

Test 2: hide PART variant from Reg-user

  • on the Tags sub-menu add the following rule:

  • go to inventory and label the chosen Part-variant:

Now go to the Customers Menu, and add the grpm_tag, to the chosen Reg customer:

Pass criteria: Part variant should be invisible to Registered customer; everything else should remain the same i.e., Pro and guest customer see Grpm and Part variants; Pro variant remains hidden to all customer types.

Test 3: show PRO variant to Pro-users

  • Add pro_cus rule:

Pass criteria: Pro variants are only visible to Pro-customers on the shopfront; the shopfront remains unchanged for other customers.

Test 4: Hide variants Grpm and Part from Pro customers, while keeping these visible to unregistered customers.

  • Create the tag part_cus and set the respective rule:

  • Add the part_cus and grpm_cus tags to the Pro customert (Customers menu):

Pass criteria: Grpm and Part variants should now be invisible to the Pro customer, but visible to the guest customer.

tag_3

The pics below summarize the required steps to achieve such a selective view of variants, for different types of customers.

image
image

Default: image

Customer rules: image

These tests can be adapted to the different tag rule types, as mentioned in the previous section.

Open Street Maps (work in progress)