I tried finding this solution but no luck. Its very simple requirement and I think cucumber has solution which I am not aware of.
I want to use same set of examples of scenario outlines to the multiple features. Every time I don't want to copy paste same set of example, it will lead to non-maintainability of feature files.
I tried with cucumber java with below example
Given The Economy is up for actions
When I make GET request to get **device** list with limit as <limit>
Then I should get success status as true
And I should get the **device** list with <limit> members
Examples:
| limit |
| 1 |
| 10 |
| 25 |
Given The Economy is up for actions
When I make GET request to get **user** list with limit as <limit>
Then I should get success status as true
And I should get the **user** list with <limit> members
Examples:
| limit |
| 1 |
| 10 |
| 25 |
Here you can see only When step is making difference, where in both steps limit examples are same. This is just an example, I have lot many cases like this in which I need to use different set of examples.
One thing which I love about testNG is data providers which will solve this problem easily. But looking forward to get similar in cucumber.
Cucumber does not provide such flexibility where we write examples/data tables only once in a feature file and access these in all other feature files.
Other side, if you do not use scenario outline in that case depending on data variation under examples lets say 3, you would have to write 3 different scenario.
If you are looking features similar to TestNG while using BDD/Gherkin, you should try pure TestNG implementation of BDD including gherkin. It is pure TestNG implementation for BDD provides all TestNG features including priority, dependency, listeners, parallel execution. It is designed for web, mobile and web-service functional test automation, providing design concepts and lots of inbuilt features required to support different use cases.
Refer
reusable-generic-examples-table-in-cucumber
examples-in-cucumber
customdataprovider-for-feature-file
creating-examples-for-scenariooutline-in-code
To share 'examples' data, you could store them in external static file (json/txt/what ever) and load them in particular steps implementation. I am not aware of out of the box solution in cucumber to share example between feature files.
Related
The problem is basically in the header: I have some scenarios with 20-30 steps and Background is not usable. So how do I split those scenarios to several ones with 5-6 steps in one scenario,as cucumber best practice suggests.
Any tips? Someone did this already ? Any examples?
First of all you can look at the subject of the feature and instead of having a file for that you can have a folder.
Lets say you have a feature login, which has now gotten really big
features
|- login.feature
features
login
login.feature
Now you can start making files to extract scenarios too
features
login
| admin_login.feature
| normal_login.feature
| 2factor_login.feature
It should be fairly clear that you can keep on repeating this pattern.
As far as analysing your scenarios in your existing files. You can
analyse your scenarios by topic and group them together
look for things that break a common background, i.e. need a different method in the background or need a new method in the background
Each of these will give you candidates to extract into new files.
You just keep on repeating this until you have clarity in all your feature files.
When writing cucumber tests in gherkin one can define a series of steps, that will be executed before each scenario
I could not find any equivalent to that for running a series of steps after each scenario.
My use case would be:
Background:
- login
- go to products page
- select product
Scenario Outline:
- Configure product in different ways
Examples:
| options |
| values |
After Each:
- go to checkout
- fill in personal data
- fill in payment data
- submit
Is there such an equivalent option that I missed in the docs?
There isn't an after equivalent by design. The point of each scenario in Cucumber is to drive the development of a particular bit of behaviour specified by the When. Because new behaviour mostly builds on existing behaviour its expected that a number of scenarios will have a common background. For example if you are writing scenarios about signing into a website (good sign in, bad password, forgotten password ...), your users will have to be registered.
The Then in a scenario is to assert that the When has worked. Anything after that should be in a different scenario.
So your examples could be
Given a product is configured with ...
When I buy the product
Then ...
All the after stuff gets moved into the before stuff, and possibly the When.
I am trying to find out if there is a work around for my validation here. Have replaced actual steps with something similar.
Is it possible to define example tables ,, and pass the entire table as data to each iteration ?
I have huge list of sub elements to be verified and so I do not want to define sub element data in each iteration separated by a delimiter .
Here is the sample scenario
ScenarioOutLine: Validate POST call for XXX to have valid sub elements under each element
Given Request headers are set
When Request is posted
Then the response body content has element <ele_name> with sub elements <Sub_ele>
Examples:
|elem_name>|<Sub_ele>|
|Dept|{Dept_Sub_elements}|
|Subject|{Subject_Sub_elements}
|Course|{Course_Sub_elements}|
Examples:
|Dept_Sub_Elements|
|IT|
|Marketing|
Examples:
|Subject_Sub_Elements|
|Anatomy|
|Physciology|
|Management,economics|
I would hide all the mandatory verifications in the steps, in a method I always call after each scenario, and not pollute my feature files with it. The mandatory elements should always be there. They are not important when you discuss what the system actually does that the end users really care about.
BDD and Cucumber is all about communication and nothing about testing.
I always work hard on hiding the technical details I my scenarios as they need to be understood by the business representatives. Technical details belong among the steps or helper code that the steps delegate to. Your mandatory elements are a technical detail from my perspective.
You can use a DataTable after the desired Given, When, or Then step.
see reference: https://cucumber.io/docs/reference#data-tables
Depending on the language you are using you should be able to find the examples online. Here is an example of specflow:
Having Tables in Example Table in SpecFlow
If you have huge data tables (hundreds of rows) then you can think about saving the data in different file (property file, json file, or even excel file)
For smaller tables, they can be mentioned in .feature files. To make it easier to read, you can use table formatter plugins for intellij or eclipse.
e.g.
https://plugins.jetbrains.com/plugin/7550-pipe-table-formatter
Why not just use a single example table as an input to the validation step? Since nothing from the examples table is altering the given or when statements, there is no value to running this scenario multiple times.
Even if you were running it multiple times, I see no value to what you are trying to do, and it just makes it harder for humans to make any sense of the examples. Given the entire point of BDD is to have a conversation with stakeholders around the feature file and the scenarios there, anything which makes it harder for humans to understand the examples is generally a bad smell where BDD and Cucumber are concerned. Thus there is negative value in terms of trying to DRY out tables
Then the resulting page should have <Sub_element> found under <Element>:
| <Element> | <Sub_element> |
| Dept | IT |
| Dept | Marketing |
| Subject | Anatomy |
| Subject | Physciology |
| Subject | Management,Economics |
| Course | CompSci 210 |
| Course | Math 101 |
I want to create a feature file that will call other feature files. Is this possible? For example, I'd like a high level feature file that says something like this (only in proper formatting):
call feature1
call feature2
call feature3
and each call goes to a feature file containing, for example:
Scenario Outline:
Given this
Then that
And more
So with this example, you'd have 1 high level feature file, with 3 lower level feature files. Each sub-feature will probably be a scenario outline.
Thanks.
There is no Cucumber feature that allows you to run a feature from another feature. You can't even call a scenario from another scenario. (You could do that in early versions of Cucumber, but it was removed.)
You can share lists of steps among scenarios in a couple of ways, however:
you can run a list of steps before every scenario in a feature file by putting them in the Background section: https://www.relishapp.com/cucumber/cucumber/docs/background
you can write a high-level step that calls a list of low-level steps: Reuse Cucumber steps
Maybe you can restructure your problem to use one of these methods.
I need to write a class for enforcing rules about items which may or may not be added to the same container in a warehouse, and I'd like to translate the requirements in to Cucumber before implementing it.
Each item has several attributes, such as "Item Family" (eg: electronics, book), "Item Status" (eg: main stock, faulty stock), and "Batch" (eg: 1050, 1051).
I can think of several strategies for writing a Cucumber test for this, and I'd like to know which is the recommended one:
Firstly, you could enumerate all of the attributes per product:
Given I have a tote containing:
| sku | client | family | status | batch | weight |
| 100000 | Foo | garment | main | 1234 | 10 |
When I add the item:
| sku | client | family | status | batch | weight |
| 200000 | Bar | garment | main | 1234 | 10 |
Then I should be told there is a Client conflict
Secondly, you could have a basic product hard-coded, and try specifying the minimum differing attributes from it:
Given I have a tote containing an item that's client "Foo"
When I add an item that's client "Bar"
Then I should be told there is a Client conflict
This assumes the step definitions hold the basic attributes, and override them when attributes are mentioned in the steps.
Finally, you could go a further step of abstraction:
Given I have a tote containing an item
And I add an item with a different client
Then I should be told there's a client conflict
Any guidance on the correct approach here?
The answer from The Cucumber Book would be whichever is most readable to the non-technical members of your team. Sit down with the QA lead and project manager, and ask them the same question. I had a similar problem, and started with something like your first suggestion. Then I decided it was too detailed and jumped to #3. Then I sat down with the project manager and found out that when I was creating the data I did not need any detail, but when we changed the data (in our case updating line item values on an invoice), we wanted to see what those values were in the steps.
Chapter 6 from The Cucumber Book "When Cucumbers Go Bad" was really helpful in directing to the right level of detail. I really think you should give it a read, especially the part about coming up with an Ubiquitous Language. I think that will help you decide on the right level of detail for your organization.
If you are tempted to use the first test, my question to you would be, "How often are you going to change those values?" If the answer is "not very" or "never", then you should consider whether they are adding to or detracting from the readability of the test.
P.S. I'm still reading The Cucumber Book, but so far it has been extremely helpful, for example pointing me towards FactoryGirl as socjopata suggested.
First option mentioned is the one that's most flexible and reusable. With the first approach you can cover basically any case you may need, but there are some cons, that you'll read about below.
The 2nd and 3rd options are easier to read, which is also an important factor while writing tests. Furthermore, the seem to focus on what is actually tested, i.e the key difference which "Foo" and "Bar" seem to make in that scenario/feature. And that's also preferred while writing tests.
Generally, imho writing Cucumber tests is like placing yourself between a rock and a hard place. I noticed that developers tend to reuse and over reuse cucumber steps creating hard to understand and maintain scenarios.
The second approach requires more work in defining steps, butscenarios are cleaner and easier to read... BUT it requires more time to write a scenario as well as it produces a large steps definition base, which can be hard to maintain.
If you really want Cucumber for bdd then I would most prolly lean to 2nd option. Just make sure you'll use FactoryGirl or something similar under the hood, to create generic object and overwrite only what you need at a time.
I hope that you find this useful.