Snappy API Test Cases
These test cases are intended to allow EPOS integration partners to showcase all the key elements of their integration. For the integration to pass, a 100% pass rate is required.
If not all features are currently supported in your integration these test cases will be ignored.
Update Product Availability | Availability API
TEST CASE 1:
Test Authentication and Authorisation Workflow
Objective:
Demonstrate the proper authentication and authorisation process ensuring the integration can be used on different businesses.
Steps:
- Explain where the OAuth ID & secret are entered in your system and outline how the secret is stored.
- Show where a business ID can be configured.
- Demonstrate any API call to show that your system correctly gets an access token.
- Demonstrate getting a fresh token when one has expired.
Expected Result:
Expected response received indicating the token was valid. Correct store was updated on Snappy. Client Secret is stored securely.
TEST CASE 2:
Check Status a Job from the products/quickupdate endpoint
Objective:
To confirm the accurate reporting of job status through the import/status endpoint.
Steps:
- Update a subset of products using the products/quickupdate endpoint.
- Use the import/status endpoint to retrieve and verify the current status of the update job.
- Once the success/failed response is received stop requesting status updates.
Expected Results:
The result correctly provides the ongoing status of the menu update job. The status update requests are not continued once a success/failed response is received.
TEST CASE 3:
Add New Product with Name, Price, and EAN
Objective:
To test addition of a new product, including essential details, to the Snappy store. Use an EAN already on the Snappy Master Menu.
Steps:
- Use either the products/add endpoint or products/quickupdate to introduce a new product with its name, price, and EAN.
- Confirm the appearance and accuracy of the new product on the Snappy store.
Expected Result:
The newly added product is visible and accurately represented on the Snappy store.
TEST CASE 4:
Retry Request in the Event of an Error
Objective:
To ensure proper error handling when attempting a request without an active connection, server error or similar.
Steps:
- Attempt to add a product while deliberately lacking an active connection or similar error which will cause the request to fail.
- Repeat with the permissions for the Snappy store not granted for EPOS. This will trigger a warning in the result which should be handled.
Expected Result:
Your EPOS system handles the lack of connection, logs the error accordingly, retries and recovers.
TEST CASE 5:
Update Product Price via API
Objective:
To validate the successful update of a product's price on the Snappy store.
Steps:
- Use the products/quickupdate endpoint to modify a product's price.
- Verify that the product's price is correctly updated on the Snappy store.
Expected Result:
The product's price is accurately updated on the Snappy store, other details should remain the same.
TEST CASE 6:
Add Products to a "342" Promotion
Objective:
To test the addition of multiple products to a "342" promotion.
Steps:
- Use the products/quickupdate OR products/promotions to add products to a "342" promotion.
- Validate that the products are linked to the promotion with all "342" promo details intact.
Expected Result:
The products are assigned to the "342" promotion, and all relevant promotion details remain consistent. Add products to cart to ensure promo is applied.
TEST CASE 7:
Add Products to a "Meal Deal" Promotion
Objective:
To test the addition of multiple products to a "Meal Deal" promotion and ensure user friendly section names.
Steps:
- Use the products/quickupdate OR products/promotions to add products to a "Meal Deal" promotion.
Check the section names are user friendly and correctly reflect the products.
Validate that the mixture of products trigger the promotion.
Expected Result:
The products are assigned to the promotion, and all relevant promotion details remain consistent. Add products to cart to ensure meal deal is applied.
TEST CASE 8:
Set Product Out of Stock with Availability Date
Objective:
To ensure the correct handling of product unavailability and the assignment of an availability date.
Steps:
- Use the products/availability endpoint to mark a product as out of stock, specifying an availability date.
- Confirm that the product becomes unavailable for purchase, and the provided availability date is accurately recorded.
Expected Result:
The product's unavailability and the associated availability date are correctly managed, the product remaining on the store as Out Of Stock will depend the store’s specific settings.
TEST CASE 9:
Update Product by Removing from Promotion
Objective:
To test the successful removal of a product from a promotion while retaining other details against the product.
Steps:
- Use the products/quickupdate OR products/promotions to update a product by detaching it from a promotion.
- Verify that the product's promotion is removed while maintaining other product details.
Expected Result:
The promotion is removed from the product, with other product information unaffected.
TEST CASE 10:
Retrieve All Available Store Products via API
Objective:
To gather a list of all currently available store products using the products/get endpoint.
Steps:
- Use the products/get endpoint to request a list of all available products.
- Receive and handle the list of products.
Expected Result:
The API delivers a complete and accurate compilation of available store products, suitable for import into your EPOS system.
TEST CASE 11:
Handle Update Order Webhook Data
Objective:
To demonstrate the proper handling of a simple order update received through the webhook.
Steps:
- Place an order on the store to trigger an order update event.
- Observe and analyse the handling of incoming order update data through the webhook.
Expected Result:
Your EPOS system correctly captures and manages the order updates.
TEST CASE 12:
Handle Order Data with refunds & substitutions
Objective:
Ensure the items in the order are being handled correctly based on their pickerStatus.
Steps:
- Place an order on the store to trigger an order update event. This order must include substituted and refunded items.
- Observe and analyse the handling of incoming order update data through the webhook.
Expected Result:
This depends on which triggers are used to send the order data. Available items should be processed, refunded and substituted items should be handled if applicable.
TEST CASE 13:
Remove Product from Store’s Menu
Objective:
To ensure removal of a product from the store's menu using the “hidden” field on the products/quickupdate endpoint.
Steps:
- Use the products/quickupdate endpoint to hide a product.
- Confirm that the product is no longer visible in the store's menu.
Expected Result:
The product is correctly hidden although it’s data is retained on Snappy.
TEST CASE 14:
Test Request Frequency Limit
Objective:
Verify that the request frequency adheres to the specified limit of no more than 1 request per store & endpoint every 5 minutes.
Steps:
- Make a series of changes for a store over a period of 2 minutes.
- These should be sent as a batch not more than once every 5 minutes rather than individually.
- Check the Too Many Requests response is handled correctly if triggered.
Expected Result:
Your system accumulates the incoming changes over the 2 minute period and processes them as a batch rather than individual requests.
TEST CASE 15:
Test Enhanced Stock
Objective:
Send Snappy specific stock figures using the stock object in the products/quickupdate endpoint.
Steps:
- Use the products/quickupdate endpoint to set a stock value.
- Snappy to confirm the stock value is updated and the items is correctly marked as in or out of stock.
Expected Result:
The stock is updated and correctly updates the Snappy store.
