I have created one feature file which has 4 scenarios. Do I need to create 4 step definitions or only 1?
If 1 then is it ok to have multiple
@Given, @When and @Then in one step definition?
You not only can place all the steps in one class, you probably should.
I generally create one major steps class for a project, correspondingly, an epic (suite of related stories/features)
I might conceivably have a separate class for steps that are common across projects (which is rare) but I generally keep all my steps in one class.
When I first started out in automation, I kept one class for each story. I use that terminology because I mostly use JBehave and it's the corresponding term for feature in Cucumber.
This tended to make us have to re-word a lot of similar steps (like log-in) to avoid potential duplicate step definitions, which is easier to avoid and easier to maintain when all the steps are combined into one class.
What I usually do, is separate these into areas of functionality.
For instance, I have step definitions relating to login functionality separated from the step definitions relating to registrations, search functionality separated from the ordering of our products functionality, and navigation separated from other various common interactions.
This essentially means that when you're searching for a step to use, you go to the file/class that best suits what you are hoping to achieve, which lessens duplicate step definitions.
If you're asking whether you need multiple step definitions, yes you do, however, if you're asking how you should group these step definitions, then it is up to you, but I would definitely recommend grouping them by functionality over something like the ticket number that it was worked on (that usually is a tag in the feature file itself).
No, it’s not necessary to create multiple-step definition classes for single feature file with multiple scenarios; one step definition file can manage multiple scenarios and multiple feature files.
Even though we can create multiple-step definition classes for different scenarios based on the functionality but it’s not necessary.
A step, as a "normal" function, should follow the Single-responsibility Principle. I.e., it should do one and only one job, perform a single step.
@given, @when and @then tags serve to increase the meaning of the phrases, but in 99% of the cases, one phrase only make sense in the context of one tag.
If your phrase contain connector, as and, or, but, probably it is doing to many things.
Gherkin has the tags
@but which are used to connect simple phrases. See it here.
At the current stage you can keep all your step definitions in single step definition file, but as your project will grow, it will be difficult to maintain one huge step definition file/ class serving a lot of scenarios.
In that state, you 'll have to break it up in multiple step definition classes, basically one for each page class and share the common state so that you don't initialize the same web driver, page objects again and again in step defs and simply use shared instances ( Singletons) across step defs.
This way your step defs will be simple and short(although multiple) and will be sharing common objects state globally.