When a piece of data that I want to assert on in a later test is derived from an earlier step, is there an accepted method of storing and recalling that data later on in the scenario?
For example:
Scenario: Recently viewed product
Given I am on a product category page
And I click on the first product
When I am on a product category page
Then the recently viewed products should list the product I just viewed
On the step And I click on the first product can I somehow persist the product name so that I can assert that I am actually seeing that product in the last step? The reason I can't specify an actual product name in the feature file is that this could and will become out of sync with live product data.
Thanks!
It's entirely up to you how you implement this. The simplest way is in your "I click on the first product" step definition store the clicked product information in a static variable (or as a global variable) and then use it in "the recently viewed products should list the product I just viewed" step to verify it's present.
Store the values you need to persist between steps as FeatureContext class properties.
Don't forget to clear them when the Scenario ends, or before each new Scenario.
Related
I want to know if it is possible to automatically reset the product quantities in shopping lists after customer places the order?
Not the order, but the shopping list itself.
Eg. Change from 5 back to 1?
You can implement it as a part of the custom checkout workflow based on one of the default workflows. For more details the documentation.
For example, that change can be a workflow action described in the last workflow transition definition and executed when the order is created.
Hello Shopify Developers.
I'm a newbie on Shopify. How can we add a tab in product pages as Dimensions? Through this tab, we should be able to edit and change the dimensions for each specific product.
Would you give me a suggestion to do that? please teach me.
Best regards, Siva.
Shopify is not designed to allow customers to enter custom dimensions and have that affect the final price of the item.
However, this can be accomplished in principle through some roundabout steps, which involve a hidden priced product and a fair bit of javascript and the use of line-item properties to link everything together.
If you're feeling ambitious and want to make such a system yourself, the basic flow would be:
Create a product that either has a $0.01 value (or whatever the lowest denomination is in your currency) or a value of whatever the cost-per-smallest-unit that you want to sell by
Update your store templates so that any products that are marked as a component product (via tags, metafields, product type, or whatever you choose to go with) do not get displayed on collection pages, search results, etc.
For your product pages that need custom dimensions, you will need to create any relevant input fields and add whatever formulas you need to convert user inputs into units of your component product
When the item is added to cart, you will need custom javascript to add the correct quantity of the component item at the same time that the main/visible item is added to the cart. At this step, I would recommend adding line-item properties to both items that would identify that they belong together.
You will need to update your cart to hide the component product and add its price to the main/visible item for display purposes, and the quantity-update and item-remove features in your cart to make sure that when the main/visible product is updated or removed the component product is updated appropriately as well.
This can be quite the undertaking to try to take on yourself, so if any of the above steps seem daunting I would strongly recommend looking for an app in Shopify's app store that can do these steps for you. There are a lot of product option/customization apps available, and many of them have free trials that you can take advantage of to see if they meet your needs.
Of course, if you have the skills and ambition to take this project on, great! The above flow should hopefully get you started, and if you need further advice on any specific step feel free to ask another question.
For our Spartacus project, we need to introduce additional Data properties in the checkout:
We have the case, that the user needs to select a delivery mode per product.
In an ideal world, upon selection, the selected delivery mode would be saved in the NGRX Store and also in the Backend to stay within the principle of the data binding defined here: https://sap.github.io/spartacus-docs/connecting-to-other-systems/#component-data-binding
Expected Data / User flow:
User goes to Checkout and to Delivery Mode Step
Custom OCC Call is made to load the supported delivery modes for each product (depends on product type and further customer specific logic)
The cart items are displayed, enhanced with a dropdown containing the available delivery modes
The user selects a delivery mode
The selected delivery mode is stored on the cart entry within the NGRX Store and saved in the backend
The new Cart totals is calculated based on the costs of the selected delivery mode
The new Cart totals is stored on the cart within the NGRX Store and saved in the backend
The user clicks on continue to get to the Review Order Step
The cart items are listed with the previously selected delivery mode
After some analysis of the existing code, we found a property deliveryMode on the orderEntry. This does not seem to be used anywhere in spartacus, but could be used to make Step 9 work by following this stackoverflow answer and this one.
Questions regarding this flow:
How can we extend the NGRX Store? We assume, it would be possible to just extend the facade (Active Cart Service), bypass the store and save the information in the backend (Described here) and afterwards refresh the store from the backend. Is that Assumption correct? If yes, that feels awkward though, as we need to reload the whole store just to contain the new property deliveryMode on the orderEntry
How can we hook into the price calculation of the cart totals to update the total based on the selected delivery mode? And again, how can we bring the new total sum into the store?
There seem to be several Answers within the Slack Channel without very few usable answers around extending the ngrx store, even though for us, it seems to be a quit normal task.. :-/
Any thoughts, inputs or support would be very appreciated. :-)
This seems like a difficult thing to accomplish seeing as delivery modes per product aren't supported as-is in spartacus. But some ideas:
You can extend core CartEntry classes (adapter, connecter, facade, etc.) to include the delivery mode for entries added to the cart. You will probably need to change all to include the delivery mode setting(s). All of these are exposed so you can modify them as needed including the store.
Utilizing multiple carts to have a product per cart and set delivery mode that way. But this would be cumbersome in my opinion.
As far as price calculation goes, I'm assuming OCC calls return total prices. Does the call for the cart entries include delivery mode costs per entry?
We have implemented the following work around and it works so far:
Enhance the Cart Model in the backend
Add new Endpoints to load the available delivery Modes per Product (by bypassing the NGRX Store)
Add new Endpoints to save the selected Delivery Mode (by bypassing the NGRX Store)
After Save Endpoint, a cart Reload is triggered, which loads the new cart totals having a custom property on the order entry (via type augmentation) into the store from the backend
It's already a lot of years past since Spartacus project started, but looks like it's still really raw projects. Spartacus is not ready to deal with real word customer's requirement and complexity of customize it quickly grow at real project(so you start to think do we really need it, as it's so unflexible at some dimentions). Some parts is really hard or not possible to customize, so you begin to search a workarounds(This question is one common case).
I think NGRX Store is one of the biggest pain in the ass to customize something at Spartacus. 2 years past and nothing changed by Spartacus team...
After creating custom product page in Blueprint and adding an option set with over 30 different options, I figured that the scss/js won't be applied to another product even if they use the same custom template, due to the fact that the only way to target each option is by using its ID. The template becomes no longer valid for another product, since the JS is targeting IDs that don't exist for the new product. Did the regular API call with the idea of copy/pasting product option ids from one product to another, but unfortunately the product option IDs are read-only. Any ideas ??? Thank you in advance.
I have a question about getting test data for automated testing, here is my problem:
I need to prepare automated testing scripts for a clothes shop.
And I need to know what is the best practice for getting test data needed for the following scenario:
Scenario description: Checking if a user can correctly add a product to the basket.
Given I am on the "WOMEN'S DRESSES" page
When I add "XXX" product to the bag
Then I can see "XXX" product displayed in the basket
My question is: how to ensure that the "XXX" product is always available and what is the best practice for this?
Do I have to always connect to the env database and check if the "XXX" product is available and if not then insert it into DB?
Or maybe should modify a little BDD scenario and get the list of currently available products on the "WOMEN'S DRESSES" page, chose any product, add it to the bag and check if it is correctly added to the basket? ( but in that case what to do if there are no products available for the testing env ?)
I want to have efficient and strong automated tests.
There are a few options for this. Some developers and I looked into a similar problem we had for a car-marketplace. We actually found out that the "dirty" way was the best way for us.
We simply did a BeforeFeature database query and picked up all brands which were available in the test environment. We added these brands to FeatureContext and ScenarioContext, depending on the required context. Because of the Feature/Scenario context, you can use these values during the run of that particular feature/scenario. During the "When" step, in the code, we created a list of all the brands available in the database.
Then, we passed every brand through specflow to the code and checked the list if it contained the brand. If the list did contain the brand, a click had to take place on that brand and we checked in the last step if we were landed on the page of that brand.
You could do something similar with the dresses.
So our specflow looked somewhat like:
Scenario Outline: Check available brands till vehicle detail page
Given I navigate to Vehichle Search Page
When I search '<Brand>', if available in test environment
Then I am navigated to the vehicle detail page
Examples:
|Brand|
|Audi |
|BMW |
|etc |
Just an addition:
This way of writing test keeps your test very BDD. Business can read what your are testing. Also, as long as the data model remains as-is, your tests are very maintainable. You can add unlimited amounts of dresses to your table and you will only get test results if the brands are available. So if the database is swiped clean, sure, not a single test will be executed, but you won't get any false positives or unnecessary negatives.
Also, you can choose to add brands to the database if they weren't found in the first place. You could do this within the "When" step. If the dress is not found in the list, you can add it with a query in the database at that moment.
In your case you have to add one more precondition:
GIVEN: XXX product is available on the "WOMEN'S DRESSES" page.
If product is not available - it's another test case )
Create XXX product just before test using most suitable way:
api call
web UI
DB update (not recommended)
or just mock api response for XXX product