-
-
Notifications
You must be signed in to change notification settings - Fork 694
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
Make strict
behaviour consistent and document it
#714
Comments
@mpkorstanje told me he thinks perhaps strict=true should still allow undefined to cause no error, because it lets people check in WIP scenarios. Maybe this is a good thing - IDK. We could also introduce more fine grained control:
That would change Alternatively we could introduce new options:
|
I think there is a case for defaulting to Adding more modes puts a burden on tooling. People expect that their reporting suite processes the results in the same way Cucumber does. So if we are going to default strict to true, perhaps we can get rid of it entirely? edit: This wasn't clear originally -half this discussion happened in slack- but I'm proposing defaulting to strict mode and removing strict all together. |
Cucumber-js has strict default to true and having it set to false only allows pending steps to not cause a failure. Undefined and ambiguous are logically the same to me as both amount to being unable to find a step definition. Pending requires more intention whereas undefined is more easily a mistake. I personally prefer we just remove the concept of strict entirely. I don't think WIP scenarios should be checked in in general (keep it on a branch). If you do check it in, I think the scenario should use a tag to mark it as WIP with the default profile having a tag expression that excludes that tag. |
So we've reached a consensus on |
Cucumber JVM has started the migration. It will take some time to get everything switched over. See: #1788 |
What are you migrating Cucumber JVM to? Not sure I see a consensus in the existing comments |
Migrating to default to strict. Then remove the option eventually. |
Unlike other implementations Cucumber-JVM defaults to `--non-strict` mode. By defaulting to `--strict` Cucumber follows the same standards as other implementations. Additionally the option to set strict mode adds complexity for consumers of Cucumbers output. They have to interpret Cucumbers 6 scenario outcomes with this in mind. By removing `--strict/--non-strict` mode we remove this complexity all together. With PR Cucumber will: * default to `--strict` * throw an error on `--non-strict`. * warn when `--strict` is used. * only print snippets as part of the exception thrown by JUnit rather then use the summary printer * only print snippets as part of the exception thrown by TestNG rather then use the summary printer Partial fix for #1788, cucumber/common#714
We have a major release of cucumber-js coming up. Thoughts on deprecating |
(or even just removing it now...) |
I would prefer deprecating it first |
Various cucumber implementations have inconsistent behaviour for
strict
:I propose we make
strict
default totrue
. By defaulting to true we're actively discouraging users from making a lot of WIP, and I think an opinionated tool like Cucumber should do stuff like that.I also propose the following behaviour:
I haven't looked into whether the various implementations behave like this. Let's agree on the desired behaviour - then create issues for the implementations that deviate so we can fix this.
When all implementations are fixed we should put this up on the docs site.
The text was updated successfully, but these errors were encountered: