Cucumber-jvm: Feature Request: Adding glueClass to CucumberOptions

Created on 24 Jul 2019  ·  14Comments  ·  Source: cucumber/cucumber-jvm

## Summary

I was wondering if the project would be open to add something like this:

  /**
   * @return class(es) to look for glue code (step definitions and hooks).
   *         Optional.
   */
  Class<?>[] glueClass() default {};

To the CucumberOptions (which now seem to be split by test framework).

Context & Motivation

The use of actual classes allows the option for easier code refactoring (renaming the class containing the glue code will automatically also rename this since it is not a string).

We as well need a more fine granular configuration in our project on which classes should be loaded (we do have classes in the same package that should not be loaded together).

We currently have a custom runner based on an older cucumber version that implements this behavior for us.

bounty $300 help wanted enhancement

Most helpful comment

We don't support classes yet but we would if were were to implement support for classes (don't know to phrase this in English :smile: )

The important bit is that loadGlue is getting too many arguments. I'd rather see something like:

loadGlue(Glue glue, GlueSelectors selectors)

Where you'd do selectors.getSelectorsFor(PackageSelectors.class) to get the package selectors.

All 14 comments

Definitely! If you're willing and able to provide a PR I would be happy to accept it.

Please do take into account that development on Cucumber v4 will soon cease so we can get v5 out of the door so please provide a PR against develop-v5 first before providing a PR against master.

@daMupfel Are you still interested in implementing this feature?

In principal yes. I don't have much time at the moment though. Since it is not a pressing issue for us at the moment i might come back later when we updated to cucumber 5 :wink:

No worries. I'll label this so every one who feels free to can pick this up.

Hi @mpkorstanje, I would like to pick this up if you don't mind!

Please feel free to do so!

Btw. My earlier comments about develop-v5 are no longer relevant. You can develop against master.

Thanks will do!

I've started to implement this feature and I have a question.
Looks like I need to change io.cucumber.core.backend.Backendinterface to something like this:
void loadGlue(Glue glue, List<URI> gluePaths, List<Class<?>> glueClasses);. Is it safe to do? Interface is marked as Api.Stattus.STABLE

That's not safe to do on a minor release but it is on a major. That said. How would this work when used from the CLI?

I was going to add new CLI argument --glue-classes. For example:
--glue-classes io.cucumber.examples.java.RpnCalculatorSteps --glue-classes io.cucumber.examples.java.ParameterTypes
If glueClasses is defined -> no default glue is picked, extraGlue or glue allowed

It feels like we're starting a primitive obsession and passing too many arguments to a single method. Perhaps we can introduce an class that lists the sources of glue explicitly.

We currently support:

  • packages (as class path uris)
  • file uris kinda (for groovy)
  • classes
  • actual uris

Could you provide example how do we support file uris and classes right now? I tried --glue io.cucumber.examples.javaRpnCalculatorSteps and it is not working.

We don't support classes yet but we would if were were to implement support for classes (don't know to phrase this in English :smile: )

The important bit is that loadGlue is getting too many arguments. I'd rather see something like:

loadGlue(Glue glue, GlueSelectors selectors)

Where you'd do selectors.getSelectorsFor(PackageSelectors.class) to get the package selectors.

Was this page helpful?
0 / 5 - 0 ratings