Extend functionality for non-reporter plugins

[mmuzikar]

Is your feature request related to a problem? Please describe.
I'm working on a project that allows test developers to write scenarios in real time. This is especially handy for UI applications where you'll be able to directly see the results of your actions. The issue is that the existing plugin functionality does not 100 % support this. My aim is to use as much as Cucumber as possible to avoid different behaviors between my runner and the original Cucumber runner.

Describe the solution you'd like
Extending existing classes that are sent to the plugins with more runtime information. For example the StepDefinition class contains only location and pattern, there is no event for interacting with type registry. I can provide the list of interfaces and also implement those interfaces. And mainly there's no easy way to match an actual step

Describe alternatives you've considered
I tried using reflection and bytecode manipulation to stop the Cucumber runner and give the execution context over to my plugin. Using reflection is not fun because it's very error prone and difficult to keep up with the internal changes.

Additional context
I can see the plugin structure used for more than reporters, it might be cool to create documentation plugins that are able to create a list of all registered steps (with the added information), transformers, etc..., automation plugins (f.e. integration with Ansible)

[mpkorstanje]

there is no event for interacting with type registry.
And mainly there's no easy way to match an actual step

I don't think extending the events is the right way to go here. I'm thinking you need something more along the lines of JUnit Jupiters extension model where extensions can inspect and modify the test context and hook into various phases of test execution. Unfortunately this part of Cucumbers core is quite poorly defined. So doing this properly is not a small project and would require a significant amount of involvement beyond what you are proposing and also some degree of assent from the other core contributors.

So realistically speaking I don't see that happen any time soon. But if you are interested in doing a major re-factoring I would suggest joining the #commiters channel in the CucumberBDD slack (links in the README).

[aurelien-reeves]

As @mpkorstanje said, this is a lot of work, and not something we want to prioritize