Im trying to figure out what the better way to do this is? On one hand separating your step definitions based on the different feature tests is nice for organization (or in case one breaks and you need to fix that specific test)

On the other hand, I find a lot of repeated step definitions (such as logging in) that end up being referenced in another file (unless I just want to change the wording intentionally).

The more i've been separating my step definitions file the most it seems like maybe it's just a better idea to keep them all in one. Is there a major downside to this im not seeing?

  • 1
    I had the same question as you but I don't understand your final decision. I thought you cannot have one step in multiple definition files. They have to be unique otherwise cucumber will say they are duplicated. Please let me know if I am wrong or misunderstanding you. I have separated feature files but I am finding I am creating a new step files that maps each feature file but then I am reusing steps (methods) from other existing step files so each feature file doesn't necessarily group all the methods i am using to test that specific feature. I hope i make sense.
    – user18505
    Commented May 26, 2016 at 3:35
  • What you are saying makes sense, basically I was asking if I should have a feature file match with a step definitions file, or if I should just have all the step definitions in one big file. I ended up grouping these into common step definitions files (not exactly a 1-1 ratio for feature to step definitions files) but more like keeping all "login" step definitions in one file, or all "expect this text" in one file. Etc...., hopefully that makes sense :)
    – Mercfh
    Commented May 26, 2016 at 15:27

4 Answers 4


BDD is more than testing; it's purpose is to enhance communication. Scenarios should be created collaboratively, thus, creating a common project vocabulary. For instance, if someone has wrote a logging action in the past and a new feature uses this flow, this person can point out the reusable way to describe the action.

One single feature file, for most project, is unmanageable both for reading/search and for developing new steps. As mentioned, separating by features is one way - by user interaction flows is another.

Since step definitions is code, you should use static analysis tools routinely to check for standards downgrades.


In my project I created common step definition file with common method like login, logout, selecting checkbox(s), setting value in input fields, taking screenshot, selecting value in dropdown, selecting option in radio button group etc. and created separate step definition files for feature specific steps.

And I was easily able to manage complete testsuite following this architechture


I have the perfect solution for your problem.

Use Page object model .PERIOD.

There will be no further confusion , because you know exactly where code resides.

Some people may still do duplicate efforts , but that can be controlled during strict Code reviews using Crucible or reviewboard etc.


Just for reference I ended up going with separating out step definitions. It made it much easier to find "ambiguous" errors when I have the same step in multiple step definition files. I've been keeping them separated as per what they are related to: IE: "Logging In"/"Checking Hyperlinks"/etc...

  • Since you asked for a opinion/sharing of experience, I don't think you should accept your own answer. Commented Jan 11, 2017 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.