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.
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.
Extending the question Cleanup steps for Cucumber scenarios. I am aware that I can use tagged #After hooks to repeat the last few steps for all scenarios matching the tag. However, this implementation will be in my java classes and my business users will have no idea. Also my acceptance tests are huge, around 200. Lets say each feature file contains 10 scenarios and last 3-4 steps are common for all of them in that feature file. So i will have 20 feature file and 20 unique tags. I can create 20 #After hooks function and silently perform those steps. But how will my business owners know this if they cannot see these technical implementation?
The purpose of 'Background' tag is to repeat the same steps at beginning of the scenarios. We could have easily achieved this by using tagged #Before hooks, then why Background tag? If we have new feature of having 'Postground' tag, which is opposite of 'Background' tag, above problem can be solved. What do you think?
Note: I have logged an issue for this, but it got closed by #aslakhellosoy. I think I did not articulate the problem statement well.
Instead of repeating the same steps one by one, you can extract helper methods to perform the individual actions those steps perform, and call those helper methods either one by one in individual steps, or in sequence from the overarching step.
That way you can still make visible to the business users what happens, without having to spell out all the individual steps.
For more information, check the Cucumber documentation on Helper Methods.
If you still have more questions (I realise the documentation on Helper Methods isn't very extensive), please join the Cucumber Slack.
As we write feature file which contains several scenarios, which contains several closely worded, closely meaning step definitions, I am thinking of numbering them. Like if a step 3 of a scenario 2 would be named as s23. I tried doing it like...
Scenario: This is my scenario
Given S21the user has some thing
When S22the user does some thing
Then S23we can make sure some thing is anything.
This is supposedly help me identify the corresponding stepdefinition implementation methods quickly, and console log message linked to the step definitions etc.
But this resulted in the numbering S21,S22, S23 etc., getting treated as integer arguments in the auto generated step definitions. How can avoid that ?
Cucumber is a communication tool, not a test scripting language. Would your business users be able to understand this notation? Would it help them make sense of the scenarios? This kind of approach defeats the purpose of Cucumber as a living documentation and communication tool, and should be avoided. If your step definitions are ambiguous, add some more context (in business readable language) to make them less so.
Your IDE should help you step between Gherkin scenarios and the source code; you shouldn't need to have to add extra information in the scenarios for this.
You also don't need to use the auto generated step definitions - they are just there as a convenience and you can write your own.
I am reading a lot about Gherkin, and I had already read that it was not good to repeat steps, and for this it is necessary to use the keyword "Background", but in the example of this page they are repeating the same "Given" again and again, Could it be that I am doing wrong? I need to know your opinion about it:
Like with several things, this a topic that will generate different opinions. On this particular example I would have moved the "Given that I select the post" to the Background section as this seems to be a pre-requisite to all scenarios on this feature. Of course this would leave the scenarios in the feature without an actual Given section but those would be incorporated from the Background section on execution.
I have also seen cases where sometimes the decision of moving steps to the Background is a trade-off between having more or less feature files and how these are structured. For example, if there are 10 scenarios for a particular feature with a lot of similar steps between them - but there are 1 or 2 scenarios which do not require a particular step, then those 1 or 2 scenarios would have to moved into a new feature file in order to have the exact same steps on the Background section of the original feature.
Of course it is correct to keep the scenarios like this. From a tester's perspective, the Scenarios/Test cases should run independently, therefore, you can keep these tests separately for each functionality.
But in case you are doing an integration testing, then some of these test cases can be merged, thus you can cover multiple test cases in one scenario.
And the "given" statement is repeating, therefore you can put that in the background, so you don't have to call it in each scenarios.
Note: These separate scenarios will be handy when you run the scripts separately with annotation tags, when you just have to check for a specific functionality, or a bug fix.
For example, I have a list of ids for a product that lives in a database and is updated daily. I need to be able to run a scenario that consumes that data and runs the same steps over each of the ids in order. However, the test should not stop because one of the ids failed in the scenario, similar to what cucumber does with the scenario outline type of tests.
We would also want to format the output of the cucumber test(s) so that each id is formatted as if it is a separate test or example in a "scenario outline."
I believe I did something similar some time ago. Have a look at this feature definition.
The "Then I should be able to get to the browse categories page" action is defined here and, as you can see, Category at line 59 retrieves data from this class. In this case I'm getting data from a CSV file, but you can just substitute it with your DB.
My Ruby is a bit basic so the code style might not look so good, but it is an example I had around to easily explain what I did. Hope this help!
Cucumber is not designed to write complex information in feature file ,
If your Data is complex , or dynamically generated , you should get Data in step definition and write a generic term in feature file .
That's the intention of cucumber , writing simple features so that non technical person can easily understand what the scenario is doing.