How to access the response of a scenario from a different scenario? - karate

I have a feature file Product.feature .I have two Scenarios Create Product and Update Product. I have created a product in Scenario :Create Product. In the following scenario(Scenario :Update Product) I want to update the details of the product created in the Scenario : Create Product using the account id which will be in the response of the Scenario :Create Product .

You have to merge the Scenario-s into one. It looks like you have mis-understood how they have to be used. This is explained clearly in the documentation:
Variables set using def in the Background will be re-set before
every Scenario. If you are looking for a way to do something only once
per Feature, take a look at callonce. On the other hand, if you are
expecting a variable in the Background to be modified by one
Scenario so that later ones can see the updated value - that is not
how you should think of them, and you should combine your 'flow' into
one scenario. Keep in mind that you should be able to comment-out a
Scenario or skip some via tags without impacting any others.

Related

How User can add Order Line Note or at less Order Note or Metadata?

Does Saleor have some minimum implementation of interaction for receiving data from client
I need to receive some data from client for special product that will be created and send to him.
As for me the best way will be order Line Note editable by user
I've tried to add new fields to CartLine after to CheckoutLine, but it's not good way because i need to modify #saleor/sdk in frontend and modify backend API.
I've tried to esaminate different custom fields like:
customerNote (OrderAddNote)
OrderLine
OrderLineInput
OrderLineCreateInput
CheckoutLine
CheckoutLineInput
CheckoutCreateInput
MetaStore
MetaItem
MetaClientStore
Metadata
and found that in all of them some notes can create only stuff users.
My question is:
What is the best way to have interaction with customer? If there is noting: Is it reasonable to change permission for Add Metadata o Add Note.
PS. How can I see metadata in dashboard orders
Metadata can be created / updated for a checkout without any special permissions and can be seen and edited from the Dashboard. Customer notes can be used as well, but have less features.

Automated testing - Best practice - getting test data before test

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

JBehave: How to run specific set of stories from the whole collection in .story file

Let's say I have a Main.story file which contains-
Login Scenario
Search Scenario
AddToCart Scenario
UpdateQuantity Scenario
Checkout Scenario
But now what if I only want to run-
Login Scenario → Search Scenario → AddToCart Scenario → Checkout Scenario and skipping UpdateQuantity Scenario
How could I possibly achieve this without removing/deleting anything from the story file.
BDD style scenarios are meant to be completely independent. In this case, you would have 2 scenarios:
Scenario: I can check out with an updated order quantity
Given I login
And I search
And I add to the cart
And I update the quantity
When I checkout
Then I get a confirmation email (or whatever)
Scenario: I can purchase items
Given I login
And I search
And I add to the cart
And I update the quantity
When I checkout
Then I get a confirmation email (or whatever)
If there's a concern about each of those steps actually being several steps and that looking really ugly in the scenario with 20 givens, so long as each of those actions is tested separately, you can use a compound step. That's a step that, in its definition, calls other steps (through code, not Gherkin). You take the same actions, but the Gherkin has far fewer entries.
The important part is that no scenario should require action from a previous scenario in BDD.
To further clarify, there is a way to re-order things if you really must, but it's very bad practice. If you choose to go that road, see this question:
How do i execute story files in specific order in serenity BDD Jbehave

REST API - Reduce number of POSTS operations

I have designed some API which have some nested resources and I am wondering how to reduce the number of POSTS when I am creating some records.
for example, I have the following resources:
/orders/
and
/orders/{order_id}/products/
at the moment I need to run two POST separately if I need to create a new order or a new order's product but I would like to reduce the time for this and run only one POST.
Is this possible? is there any documentation I can read about this?
Thank you
Although you might have found your answer in an other thread there is still some issue regarding your endpoint design.
The first intuition that your endpoint give is that product resource could exist in several place.
./orders/{order_id}/products/{prod_id}
./products/{prod_id}
The question you should ask yourself is: Do you really want to refer to product?
Can product be leaving outside of any orders?
Having a resource sitting in 2 different place might not be that great as you are managing 2 different endpoint with similar behavior. Keeping consistency between both endpoint is not that easy.
My 2 cent is to avoid the term product as it can be confused with a single instance of a product. For example if you sell a toothbrush branded AAA, sku 1234 an order is not compose by this product but by one off the item that you have in stock. The item is "instance" of the toothbrush branded AAA, sku 1234.
As I understand your question you are not really referring to a product but more to a stock-item which should be a unique id.
The resource stock-item if you decide to have one should exist prior to the order. I guess the customer is not adding item to your stock and at the same time purchasing this item.
In conclusion I think that you are not creating the stock-item resource at all when creating orders but just making a reference to it.

Asserting on data that is derived from a previous step

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.