The cucumber.options system property should only override specified options.

[tychobrailleur]

When setting the "cucumber.options" system property, all the cucumber options
are overridden, including glue and feature path. This is an issue for junit
for two reasons:

• This is against the logic currently present in RuntimeOptionsFactory which
  sets glue and feature path to default values based on the JUnit test case
  if they are not set by @Cucumber.Options.
• This makes the definition of cucumber.options in a Maven pom file awkward,
  as you have to re-define glue and feature path as a system property, even if
  you have correctly defined the path to the resource folder containing
  feature files.

[aslakhellesoy]

I like what you have done here.

I'd like this to behave the same for the CLI runner as well, not just when using the JUnit runner.
I think a better approach would be to implement this sort of merging inside the RuntimeOptions class.

Essentially - parse argv first, and then parse the value of cucumber.options, which would just add stuff on top.

WDYT?

[tychobrailleur]

I had actually started with a similar approach, but then backtracked as I thought that behaviour was actually desirable for CLI. If it isn't, then I am more than happy to push down the processing into RuntimeOptions.

[aslakhellesoy]

Awesome!

One thing to be aware of is tags. Let's assume the user has "--tags @foo" defined in the JUnit class or POM file.
What would happen if the user now did -Dcucumber.options=--tags @bar?

The tags would now be --tags @foo --tags @bar. This will only run the scenarios that have both of those tags, while the user probably intended to only run the scenarios tagged with @bar.

So if you go ahead with this it would proably be a good idea to throw an exception if tags are specified both in argv and cucumber.options, or possibly just clear the argv tags first if there are tags in cucumber.options

Other options should be fine to just overwrite (scalars) or append (lists).

Later I'd really like to implement a tag logic parser so people can say --tags "@foo && !@bar || @zap" and only allow --tags to be specified once. I think this would reduce the complexity for this and make it more intuitive for users.

[tychobrailleur]

My thinking was to ignore the tags (and other options, including glue and feature path) set in argv if they are set in cucumber.options so that they can be easily overridden when running mvn -Dcucumber.options="...", but reading your comments again, you seem to favour the sys properties being added to the existing options. I much prefer the first approach, as I can then modify all props externally. Are you ok with that?

[aslakhellesoy]

D'accord!

[tychobrailleur]

Aslak, I have now updated the code as per our discussion. Let me know if you require further changes.
Regarding your note about the tag parser earlier, what would you expect the || operator to do? I find that tag combination quite interesting!

[aslakhellesoy]

Thanks! I'll try it out when I have time.

[aslakhellesoy]

Check my cucumber_options_improved branch. I made some changes after yours. Do you agree with this?

[tychobrailleur]

You lose the ability of making it "non-strict" or "non-monochrome" by overriding with cucumber.options. Definitely not a big issue for me, but this is what I meant by the sys props giving more flexibility by overriding everything (except glue / path when not set). If you're ok with that minor downside, then I'm good!

Tusen takk! (=

[aslakhellesoy]

Zut, I hadn't thought about that. In Cucumber-Ruby, boolean flags can be explicitly turned off with --no-strict etc. It should be fairly easy to implement that to accommodate for this issue. I'll give it a go.

[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.