-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Tag expressions are lost when specifying external feature file locations #1985
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
🐛 bug
Defect / Bug
Comments
mpkorstanje
added a commit
that referenced
this issue
Jun 5, 2020
The feature option can be used with either a rerun file or a feature path. For example when used as a property: ``` cucumber.feature=path/to/features cucumber.feature=@path/to/rerun.txt ``` Cucumber options consist of a hierarchy of options. When the feature options is used with a rerun file; tag and name filters from the previous level should be removed. This ensures that all scenarios in the rerun file and only the scenarios in the rerun file should be executed (unless the selection is filtered more at this or the next level). When used with a feature argument without a line filter this should not be the case. However `builder::addRerun` would be invoked anyway. When parsing `cucumber.feature` for rerun files, when no rerun files are present an empty collection is returned. Because `splitAndMap` was used rather then `splitAndThenFlatMap`, `builder::addRerun` would always be invoked. Fixes: #1985
mpkorstanje
added a commit
that referenced
this issue
Jun 5, 2020
…ent (#1986) The feature option can be used with either a rerun file or a feature path. For example when used as a property: ``` cucumber.feature=path/to/features cucumber.feature=@path/to/rerun.txt ``` Cucumber options consist of a hierarchy of options. When the feature options is used with a rerun file; tag and name filters from the previous level should be removed. This ensures that all scenarios in the rerun file and only the scenarios in the rerun file should be executed (unless the selection is filtered more at this or the next level). When used with a feature argument without a line filter this should not be the case. However `builder::addRerun` would be invoked anyway. When parsing `cucumber.feature` for rerun files, when no rerun files are present an empty collection is returned. Because `splitAndMap` was used rather then `splitAndThenFlatMap`, `builder::addRerun` would always be invoked. Fixes: #1985
Cheers! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When specifying the command line argument
cucumber.features
, the tag expressions that classes are annotated with are lost while the cucumber options are being parsed. I am using multiple annotated classes to define contexts which run different sets of features. The tag expression tells each context which set of features they should be running. This is important as we're using Spring profiles to inject a set of components, including the glue code, depending on the current context. An example annotated class is as follows :The respective glue code located within the same package is annotated so that a spring context is created with a specific profile.
This structure works perfectly using the command line tag filter, e.g.
-Dcucumber.filter.tags="not @Context1"
will ignore this sub set of tests. However, when specifying externalised feature files the tag expression gets set to an empty list. This lack of filtering results in each context attempting to run the feature file and many errors due to unmatched glue code.To Reproduce
Steps to reproduce the behavior:
tmp/features/ctx1.feature
tagged with '@Context1`.-Dcucumber.features=/tmp/features
command line argument to test execution.context1
andcontext2
contexts are loaded and attempt to run the feature file.PendingException
is thrown.Expected behavior
When external feature files are provided at runtime, I would expect the tag expression to be retained so that each context can run any features/scenarios in that path that match this expression.
Context & Motivation
There is a requirement that the testing framework I've created is able to run in multiple environments, where each environment may have it's own set of test cases. So externalising the feature file location, while still retaining the defined tag expressions, would allow us to satisfy this requirement.
Your Environment
The text was updated successfully, but these errors were encountered: