Hello 👋
I'm a maintainer of BDD testing tool. One of the popular requests I'm getting from consumers - to allow duplicate step definitions bound to different features. For example, I need to test an application that has "game" and "video-player" pages. Both pages have PLAY button in the interface. I write two scenarios:
game.feature
Given I have not started a game yet
When I click the PLAY button # <- duplicated step
Then the game begins
video-player.feature
Given I am watching a youtube video
When I click the PLAY button # <- duplicated step
Then the video plays
Step implementation for I click the PLAY button is different for each feature.
Official Cucumber docs says it's an introduced interesting feature called . You should make it more complex, splitting on common steps + pairing pattern steps.
Pairing can't be resolved without reading the configuration. That is mostly for tools like IDE extensions, for navigating to step definition by cmd + click. Currently, the most popular one .
We can introduce steps scope - a file or directory with name in parenthesis, e.g. (game) or (video-player).
Step definitions inside scoped directory are applicable only to features inside that directory.
This is the only rule one should know to understand the approach.
Now we can define the file structure:
└── features/
├── steps/
│ └── common.ts
├── (game)/
│ ├── game.feature
│ └── steps.ts
└── (video-player)/
├── video-player.feature
└── steps.ts
(game)/steps.tsare applied only togame.feature
(video-player)/steps.tsare applied only tovideo-player.feature
steps/common.tsare applied to both
The main advantage is that any tool or human can understand paring without reading configuration.
The configuration itself simply defines steps glob without any patterns:
stepDefinitions: 'features/**/*.ts'
Some projects have separate directories for features and steps. For such cases, the rule can be slightly enhanced:
Scoped step definitions are applicable only to features having that scope in the path.
Now the following structure is also possible:
└── features/
├── steps/
│ ├── common.ts
│ ├── (game).ts
│ └── (video-player).ts
├── (game).feature
└── (video-player).feature
- steps from
steps/(game).tswill be applied only to(game).feature, because feature path contains(game)
- steps from
steps/(video-player).tswill be applied only to(video-player).feature, because feature path contains(video-player)
- steps from
steps/common.tswill be applied to both features, because there are no scoped directories in steps path
Such file structure explicitly shows how features are connected to steps.
Conclusion
I think, scoped duplicate steps are reasonable, especially for testing large applications. I haven't seen file-based solutions before and would appreciate any feedback from you. All of you have different projects with unique structure. Feel free to share, how that solution matches your setup.
Thanks in advance and happy testing ❤️
SOCIAL SHARE CARD GENERATOR