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

Go on /shops
Make several order for an ongoing OC, but for the same product
Login with super admin (and/or the producer / shop where you put the orders)
Go to /admin/orders/bulk_management
Are you able to change weight and was the order total recalculated accordingly?
Are you able to change quantity and was the order total recalculated accordingly ?
Are you able to cancel an order ?
Are you able to add columns ?
Are you able to search for a product?
Are you able to change the dates and see results accordingly?

Checkout

Start preferably on desktop using Chrome for Windows (Number 1 use case) :
Go on /shops
Select an open shop and add item to the cart
Press continue
See your cart, but go back “continue shopping” in order to add another product
Press continue
Delete one of the first product you’ve added on the cart and change the quantity on another one
Proceed to checkout, and login
Select delivery and cash payment option
Check you get a confirmation and a confirmation email
Check your order is appearing correctly in /admin/orders
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.
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

create an order with OC fees in an OC
remove product from OC
edit order and recalculate fees. It should be correct.

Then same as above but for closed order cycles:

create order with OC fees
close the OC
edit order and recalculate fees. It should be correct.

Complementary test

As customer:

Make an order selecting the payment method earlier.
Check that the transaction fee is correct.

As enterprise manager:

Create an order selecting the payment method earlier.
Complete the order without capturing payment. Check that the transaction fee is correct.
Capture payment. Check that the transaction fee is still correct.
Create another order.
Complete the order without capturing payment.
Mark the uncaptured payment void. This should not fail.
Add another payment to the order. This should not fail.
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:

Configure the hub to allow pick-up shipping method, with no shipping fee.
Create a payment method with "Bogus" as provider. Set a non-zero fee for this.
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

Check out with pick-up for shipping alnd cheque for payment.
There should be no shipping adjustment for the customer in the report.

Check failed/invalid adjustment is not included

Attempt an invalid checkout using Bogus payment method.
There would be no payment adjustment for the customer in the report yet.
Complete the checkout with a valid card number for Bogus again.
There would be an entry for the payment transaction under the customer. The amount should be correct, not double.

Sanity check

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.
Check that the "Enterprise Fee Summary" link is available in the Reports page
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
Do a smoke test that the correct filter options are available to each user role.
Check that orders for orders cycles to which their enterprise is not participant are not available to the user.
Test that using each filter field works. (No need to do this for each user role.)

Multiple languages :

Check that the language selector is showing all available languages both on mobile and desktop
Select a language and see if it’s working on several pages of the shopfront

Product & inventory import

For large files:

Prepare a CSV file with more than 120 lines.
(For Chrome) Open the Network panel of Developer Tools. Filter results to _data: We want to see requests for validate_data and save_data.
Upload the file.
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.
When the file is being saved, there should be 3 HTTP requests for save_data that happen also one at a time.
Test a random row from each batch of 50. The row should have been processed successfully.
Introduce an invalid row to each batch, and upload the file.
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:

If blank - Read as "Use producer stock settings", so "on_hand" should be blank.
If "true", "TRUE", or "1" - Read as on demand of "Yes", so "on_hand" should be blank.
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:

Product for which the shop is the supplier
Product with permitted supplier - Have the supplier grant "add to order cycle" permission to the shop.
Product in an outgoing exchange for a completed OC of the shop
Product in an outgoing exchange for a currently open OC of the shop
Product in an outgoing exchange for a future OC of the shop
Unrelated product

Then, to test:

Create a subscription for the customer.
Without saving the subscription, attempt to add Products 1 to 6 above. It should not be possible to add Product 6.
For Products 1 to 3, there should be a warning: "There are no open or upcoming order cycles for this product."
Save the subscription. This should be successful.
Edit the subscription. In the review page, Products 1 to 3 should have warning: "Unavailable"
Click to edit products in the subscription. There should still be warnings for Products 1 to 3.
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:

Testing Subscriptions · openfoodfoundation/openfoodnetwork WikiGitHub

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.

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