How can I specify step definition file for each feature file?

My Goal

I am trying to create a scalable structure of features and step definitions for a large application and my first shot was trying to link step_definition files to features so that I could use the same step pattern for different step definitions.

My Code

I show my current example:

My folder structure:

/features/sample.feature
/features/example.feature
/features/step_definitions/sample_steps.js
/features/step_definitions/example_steps.js
/features/step_definitions/common/common_steps.js

In my sample.feature I have:

  Scenario: Launching Cucumber
  Given I have some step definitions
   When I check some step definition with parameter "any"
   Then I should see all green "sample"

In my example.feature I have:

  Scenario: Launching Cucumber
  Given I have some step definitions
   When I check some step definition with parameter "any"
   Then I should see all green "example"

The Given and When steps are defined at /common/common_steps.js file and works fine.

The Then step is defined both to sample_steps.js and example_steps.js but differently.

In my sample_steps.js I have:

Then('I should see all green {stringInDoubleQuotes}', (arg) => {
   if (arg !== 'sample') {
     throw 'I should see all green when the argument is "sample"';
   }
   return;
 });

And, finally, in my example_steps.js I have:

Then('I should see all green {stringInDoubleQuotes}', (arg) => {
   if (arg !== 'example') {
     throw 'I should see all green when the argument is "example"';
   }
   return;
 });

The Error

My main goal is to have all green here, but of course, it doesn’t work and I get this obviouly error:

Multiple step definitions match:
   I should see all green {stringInDoubleQuotes} - features\step_definitions\example_steps.js:6
   I should see all green {stringInDoubleQuotes} - features\step_definitions\sample_steps.js:6

Cucumber-JVM

I know that in cucumber-jvm we can specify a glue attribute that links features and step_definitions and it’s exactly what I’m looking for, but in cucumber-js. Example in Java:

@RunWith(Cucumber.class)
@Cucumber.Options( glue = { "com.app.stepdefinitions.common", "com.app.stepdefinitions.sample" } )
public class SampleFeature{
}

@RunWith(Cucumber.class)
@Cucumber.Options( glue = { "com.app.stepdefinitions.common", "com.app.stepdefinitions.example" } )
public class ExampleFeature{
}

Finally

How can I achieve the same as cucumbr-jvm using cucumber-js?

[unional]

IMO scoping is definitely needed. As your application grows, the number of features expands and you will end up with conflicting descriptions in different contexts.

In my company, our product has hundreds of features and QA has test cases in 100k range. If we use cucumber we will definitely run into this problem.

Yes, I think you should consider context instead of scoping. You can have most, if not all, of your step definitions in the default context (or no-context), but there should be a way to specify the context without the need of a custom DSL.

It is the BA and QA who should be writing these tests and any custom DSL is bounded to create confusion and resistance.

The Feature/Scenario already provide contexts by definition, that’s why the Gherkin syntax has the indentation.

Adding tags and custom DSL is a workaround of implementation limitation (i.e. a hack, IMO) instead of a solution.

Maybe you can consider this while considering https://github.com/cucumber/cucumber-js/issues/745 ?

How about extending Scenario from defineStep and pass {Given, When, Then} into the callback?

i.e.:

import {defineSupportCode} from 'cucumber'

defineSupportCode(({ Scenario, Given, When, Then }) => {
  Given(...)
  When(...)
  Then(...)
  Scenario('<match scenario description>', ({ Given, When, Then}) => {
    Given('<take precedent of non-contexted>', ...)
    ...
  })
})

[richardlawrence]

This is an area where Cucumber is particularly opinionated. It’s built around the belief that teams should grow a ubiquitous language, where words and phrases mean exactly one thing in the context of an application and are used consistently. Keeping step defs global maintains a positive pressure to avoid ambiguity.

In the rare cases where an application has multiple distinct bounded contexts (in DDD terms), you would simply divide your Cucumber suite along the same lines your application is divided to reflect that boundary, and step defs would be global within each bounded context.