Cucumber-js: question: documentation of API usage

[NoNameProvided]

I would like to use cucumber-js with cypress or webdrive.io. For this it's required to run cucumber-js inside the cypress/webdriver.is test suite. I have searched but I haven't find any documentaion about consuming cucumber-js through an API instead of the CLI approach. What I am currently looking for:

• passing custom dynamcic world (I need to reference cy to run my tests inside steps.)
• loading feature files dynamically

Is there any consumable api for this I havent found?

[mhoyer]

This seems to be also quite relevant for https://github.com/webdriverio/wdio-cucumber-framework/issues/95

[charlierudolph]

No work that I'm aware of has gone into documenting how to use the javascript API. Some of the cli / runtime are exposed and relatively stable.

I guess one way we could go about this is to discuss the desired API and then once we have a set of requirements, we can morph the API to fit and document that. I'm guessing we need something that is in between the CLI and Runtime interfaces.

For passing a custom dynamic world, are you saying you want something different than setting the world constructor?

Can you give more detail about loading features dynamically. Is this in a different way than what the CLI looks like.

[mhoyer]

I only have experience with the webdriver.io cucumber adapter. The idea here is use the provided WDIO CLI as main runner where cucumber is called via an API through a framework adapter.

Yes, there were days when we (in our project) used WDIO as main world instance where the cucumber CLI was the actual runner. But since there is this abstraction of framework adapter available in WDIO it makes sense to use them. See also other adapters: http://webdriver.io/guide/testrunner/frameworks.html

I am currently trying to use the Runtime class to update wdio-cucumber-framework to support cucumber 4 (currently it's still only targeting 2.3) and I somehow feel the issues with the cucumber API.

For example, I am wondering why this EventDataCollector exists at all 😏. E. g. why do all the events that got emitted don't have a payload with the full context (gherkinDocument, currentScenario, currentStep)? This would make such a collector maybe obsolete? But maybe I am missing something here.

I bet, there are many other ideas, suggestions and requirements. Let's see where this goes.

[iongion]

This issue re-emerged for us today also due to integration with other runners.
The case for having an API is still very valid.
Any plans on it ?

[RobertDiebels]

Also encountering this. Currently building a e2e-testing framework. I'd like to test this framework. To do this I'd prefer to have API access to the runtime. Some classes are being exposed though they're undocumented nor defined in the Typescript definitions file. This leaves me with the impression that the classes, even-though they're exposed, are not to be used for production.

If someone could provide an update on this issue and could either confirm or refute my assumptions that would be awesome.