pass the step definition options to function wrapper

[lgandecki]

It would be helpful to have the options available in the wrapper.
Then I can do something like this:

defineSupportCode(function ({setDefinitionFunctionWrapper}) {
    setDefinitionFunctionWrapper(function (fn, options) {
        let retryTest = isFinite(options.retry) ? parseInt(options.retry, 10) : 0
        let wrappedFunction = isAsync(fn) || config.sync === false
            ? wrapStepAsync(fn, retryTest) : wrapStepSync(fn, retryTest)
        return wrappedFunction
    })
})

I'm currently writing a "wdio-cucumber2-framework" (which is a wrapper around cucumber 2 to allow webdriverio runner run cucumber tests), and this is the cleanest way for me to implement retrying (this is how it was done in wdio-cucumber-framework as well , with the options)

Please let me know what you think, I hope you don't feel like this is too much of a feature creep. :-)

Thanks!

[charlierudolph]

Can you please add a feature test for this where the options are made use of? Maybe something similar to this feature?

[lgandecki]

@charlierudolph Thanks for the feedback!
I added the feature test. It's a bit tricky because I can't think of a good way of using the options inside the wrapper if not with an external runner - which would require quite a complex test here.
It does check whether the options are passed and can be used.
Let me know if you think of a better way to test this, or better way to name the steps/scenarios. :) I always find it hard to write human-readable specification for such a low level functionality

[charlierudolph]

I'm hesitant about this as it means options can now be filled with non-standard options. Thoughts on putting the the wrapper options in a specific child wrapperOptions. Thus this would become

When(/^I run a step with options$/, {wrapperOptions: {retry: 2}}, function () {

And in setDefinitionFunctionWrapper it is passed the fn and options.wrapperOptions

[lgandecki]

I don't have a strong preference, besides the fact that {wrapperOptions: {}} introduces noise to otherwise such a nice an readable API :) .. it will also differ from the current implementation of retry in the wdio-cucumber-framework - although it doesn't have to be backward compatible.

Maybe @christian-bromann would have something more to say?
Would you be happy with the {wrapperOptions: {retry: 2}}?

[christian-bromann]

I agree with @lgandecki here. I don't see any harm in allowing non-standard options.

[charlierudolph]

The problem with non-standard options is if somewhere down the line cucumber adds a retry option and now that is used for multiple things. By having wrapperOptions, the content is specifically for the setDefinitionFunctionWrapper function and can never clash with future cucumber-js options

[christian-bromann]

@charlierudolph if you guys add a retry function and it would break stuff in wdio-cucumber-framework that would be ok. You guys should not care about compatibility with 3rd party integrations if you bump versions correctly.

[charlierudolph]

I'm still pressing for using wrapperOptions so users are not confused as to what is a built in cucumber-js option and one that is being used by a step definitions wrapper (which the user or a framework can define).

[christian-bromann]

If this is a blocker for you I would be fine with introducing wrapperOptions

[charlierudolph]

I would consider this a blocker for me. I am good merging this in if we use wrapperOptions though

[lgandecki]

Looks like we have a decision. Not the best for us, but hey, can't have everything ;)
tests seem to be passing, looking forward to the new release so we can move forward with the wdio framework :)
Thanks!

[charlierudolph]

Cool. I added a couple small cleanup commits. I should be able to merge and release this today.

[christian-bromann]

Awesome, thanks so much @charlierudolph

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.