You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See also this related discussion about not allowing multiple step definitions: #678
Desired behavior
I would like to challenge this and introduce a configurable parameter that explicitly allows the usage of multiple step definitions (and returns the first match in case of multiple step definitions).
I am testing a web application that is localized for different markets in different countries.
These countries introduce small differences (think taxes, product data requirements, ..) but the application is 95% the same in all markets.
This means I can also re-use 95% of all my tests and my methods but I need to override a small part of those functions.
Through the stepDefinitions param and the usage of environment-specific config files (.cypress-cucumber-preprocessorrc.json) I can simply override the files that are processed and through defining the order I can also control which step is found first.
This would allow me to run my tests with the following structure:
cypress
- e2e
-- common
--- steps
--- steps/homepage.ts #contains steps that are valid in all countries
--- steps/homepage.US.ts #overrides steps for the US-market, found first when the US-configs are applied
My suggestion would be to introduce a new param (allowMultipleStepDefinitions, default false) and if this param is set to true then the first matched step would be returned. I can create the PR for this.
What do you think? Would you handle this differently?
Thanks for taking the time and taking this into consideration.
What do you think? Would you handle this differently?
I would definitely handle this differently and this doesn't warrant a change in the library. You can EG. configure an environment variable which you read in the step definition and act on accordingly.
Hi @badeball, yes, of course we could handle different behaviour based on an environment-variable. But as we are handling a lot of different countries and markets (5+) this would lead to a lot of messy code. We would prefer to keep it clean and work with overrides.
So, I do not agree with you that this does not warrant a change in the library - but ultimately it is your decision.
Current behavior
Multiple step definitions are not allowed. When multiple step definitions are found a
MultipleDefinitionsError
is thrown.https://github.com/badeball/cypress-cucumber-preprocessor/blob/master/lib/registry.ts#L171
See also this related discussion about not allowing multiple step definitions: #678
Desired behavior
I would like to challenge this and introduce a configurable parameter that explicitly allows the usage of multiple step definitions (and returns the first match in case of multiple step definitions).
I am testing a web application that is localized for different markets in different countries.
These countries introduce small differences (think taxes, product data requirements, ..) but the application is 95% the same in all markets.
This means I can also re-use 95% of all my tests and my methods but I need to override a small part of those functions.
Through the
stepDefinitions
param and the usage of environment-specific config files (.cypress-cucumber-preprocessorrc.json
) I can simply override the files that are processed and through defining the order I can also control which step is found first.This would allow me to run my tests with the following structure:
My suggestion would be to introduce a new param (
allowMultipleStepDefinitions
, defaultfalse
) and if this param is set to true then the first matched step would be returned. I can create the PR for this.What do you think? Would you handle this differently?
Thanks for taking the time and taking this into consideration.
Test code to reproduce
Versions
Checklist
cypress-cucumber-preprocessor@4.3.1
(package name has changed and it is no longer the most recent version, see #689).The text was updated successfully, but these errors were encountered: