Support CucumberOption tags in property includeFeatureTags
AdamPike opened this issue · 5 comments
Is your feature request related to a problem? Please describe.
Currently I have to set to lots of tag properties - 1 for cucumber via Cucumber Options, another for Cucable plugin.
Describe the solution you'd like
Check for --tags in the argument sent to setIncludeScenarioTags, and take everything after it minus any quotes.
Additional context
I have made this change locally and added a new test for it. I was unable to push a branch for raising a PR.
ERROR: Permission to trivago/cucable-plugin.git denied to AdamPike.
Hello, usually there is no need to specify both Cucable's includeScenarioTags and cucumber options. The Cucable option filters which scenarios should be generated and the cucumber options filter which scenarios should be executed. So instead of using both, you could just use one.
@laxersaz Thanks for the reply, I'll try and explain our use case a little better.
We have a large team of developers who are being coached on BDD, for many this is their first foray into the world of automated integration tests too. So we want as a low a barrier to learning as possible. To this end our Cucumber Maven project has 2 profiles, one for local development and another for CI execution. The second is where we use Cucable to help run in parallel. Locally the engineers are familiar with CucumberOptions and we now have over a thousand scenarios, I don't want them to have to wait for Cucable to generate all of those files, nor do they need to run in parallel so the local profile makes sense. I also would prefer the CI profile to be as efficient as possible so would rather have the tags defined for it's includeScenarioTags property, but I'd also rather not have to document a separate execution command using a different property for the same set of arguments. It just confuses people.
It is cool that you want to lower the barrier. However, having two separate profiles for CI and local is overhead in my opinion. We used to do it this way as well but eventually we changed everything to just one profile that can be used both locally and on CI.
This uses Cucable in both cases to specify the scenarios and runners to be generated.
The thing is that the Cucumber options and the Cucable includeScenarioTags are not doing the same thing so they should not be mixed up or merged. In fact, I know that some Cucable users specify both differently.
If you want to keep both profiles, you could also define a property in your POM (e.g. tags) that is used as Cucumber options or Cucable includeScenarioTags respectively.
At this point, I think having Cucable respect Cucumber options will be more confusing for other Cucable users so I would not include it in this project.
Hi @laxersaz, thanks for your thoughts. I am surprised that people set both differently. I can't imagine a situation that benefits from that. I guess from my perspective tags are a single property, I just have more than one actions from them, which is commonly the case for properties.
"If you want to keep both profiles, you could also define a property in your POM (e.g. tags) that is used as Cucumber options or Cucable includeScenarioTags respectively."
This wont work, as Cucable and Cucumber expect them in a different format, and that's my reason for wanting this.
No worries, I'll keep this on a fork for us to use https://github.com/AdamPike/cucable-plugin.
Let me know if you ever want it merged and I open a PR.