Question: Best practice for handling multiple step definitions with the same text

[banjahman]

I've been migrating a large application from cypress and trying to reuse as much of the Gherkin syntax as possible. So far playwright and playwright-bdd have been a life saver.

One issue I'm running to is the case of same step definitions in different feature files. Here's an example scenario to illustrate what's happening

Games.feature
...
Given I have not started a game yet
When I click the PLAY button
Then the game begins

VideoPlayer.feature
...
Given I am watching a youtube video
When I click the PLAY button
Then the video plays

I have both of these features defined as fixtures in a single project.
When I run npx bddgen it fails with the error Multiple step definitions matched for text: "I click the PLAY button"

What is the best practice for using steps with the same name and preventing them from matching steps in other fixtures? Is there a way to set precedence based on filenames? If I'm running the VideoPlayer tests, I would expect it to find the corresponding step in the VideoPlayer steps defined in the fixture, not throw an error saying it also found a step with the same name in the Games fixture. So far I've been renaming the steps to be slightly different, but this isn't sustainable as time goes on and wanted to get your input.

Thanks!

[NikkTod]

Make the button name to be dynamic, this way you can type any button name you can have, for example

When I click the "Play" button
When I click the "Stop" button
When I click the "Submit" button

Put this step defenition in something like a common.page

@when('I click the {string} button')
async clickButton(buttonName: string) {
await this.page.getByRole('button', { name: buttonName }).click();
}

[vitalets]

@banjahman there was a discussion for that some time ago, please have a look on this comment: #50 (comment)

So for now the best practice is try to avoid duplicate step definitions.
Although I agree with your case, it is totally valid - the same step can have different meaning in the different contexts. Especially for decorator steps, where we know the context - it is the current POM fixture.

I think about introducing a separate option for that, e.g. allowDuplicateDecoratorSteps: boolean. When enabled - playwright-bdd will take step from the current POM fixture, even if there are the same steps in other fixtures. When disabled (default) - we follow BDD practices and deny duplicate steps.

Btw, did you have duplicate steps in cypress?

[banjahman]

@vitalets that's exactly what I'm looking for. I think having an option for that would be very beneficial. I can help in adding this in if you would like some assistance and feel this is a worthwhile feature. For now I have just been adjusting the steps to be worded slightly differently.

We do have duplicate steps in cypress and the behavior there is the same as you described. It looks in the current POM for a match and uses it if there is one, otherwise it will proceed to search through other POM's until it finds a match. I don't know if that's baked into cypress directly, or if it's coming from the preprocessor plugin(https://github.com/badeball/cypress-cucumber-preprocessor)

I'm guessing the latter since it has to do with the Gherkin side of things.

[vitalets]

I've re-checked - yes, it comes from Pairing feature of cypress-cucumber-preprocessor. I like this approach even more than config option, b/c it allows to handle duplicate steps for non-decorator style.