Cucumber forces Integer type on a \d+ capture group #658
Comments
yktoo
changed the title
|
Not sure this is a bug or a feature. "\d, \D: ANY ONE digit/non-digit character. Digits are [0-9]" so it imho it really should be a digit (int) and not a String. Also note there have been some breaking changes on major versions. Please check the migration guides here. |
Alright, but how do you handle the input like the |
|
@yktoo how does this work? @When("^I type (\\d+) into input field$")
public void register(java.math.BigInteger value) { |
|
Nope. |
|
@aslakhellesoy in the Prior to v3 we used to throw everything at XStream and most of the time we'd get something usable back. Cucumber expressions does have all those smart type conversions build in. Can't try this out but if you use the Cucumber Expression instead it should be at bit easier: But since you're entering strings you may well do which will match |
|
@mpkorstanje That is indeed my workaround to use I have two other humble thoughts on the matter:
|
Mostly because of an imperfect migration. Cucumber used XStream to handle all the type conversions. We had to stop using XStream because it fails to work modern Java versions. The next best replacement was then serendipitously created Now a while ago we did add |
|
I think this will work: @When("I type {bigint} into input field")
public void register(java.math.BigInteger value) {My motivation for creating the Cucumber-Expressions library was to provide a simpler alternative to RegExp which many people seem to struggle with. It then made sense to move the RegExp logic into that library so we have a consistent way to transform capture groups (or cukexp output parameters) to other types. Another motivation was to introduce the concept of parameter types. I think So for me, improved UX was the primary motivation and it coincied with the need to get rid of XStream. Because While we've done our best to keep the RegExp support backwards compatible, there are some edge cases where the behaviour has changed or is buggy. This will be a fun one to fix! |
aslakhellesoy
added
library: cucumber-expressions
🐛 bug
|
I think #659 is a good solution but I'm going to let it percolate a bit. The short version: If we have a matching regex and it's of the right type, use that. If not treat it as an anonymous parameter type. There is a flag to override this behavior. This flag is off for all basic types. But will be on for all user defined parameter types. This solution assumes that if you are using regex and you define a parameter type you really want that type. I'm not sure if this assumption is correct.
Yeah. |
|
Pushed the wrong branch. |
When there is a conflict between the type hint from the regular expression and the method prefer the the parameter type associated with the regular expression. This ensures we will use the internal/user registered parameter transformer rather then the default. Unless the parameter type indicates it is the stronger type hint. Reasoning: 1. Pure cucumber expression users will not notice this in either scenario. 2. Pure regular expression users will benefit because `BuiltInParameterTransformer` can now seamlessly transform any captured values. (For all built in types useRegexpMatchAsStrongTypeHint is explicitly set to false.) 2. Regular expression users that define a default transformer have little need to define parameter types. The default transformer should be sufficiently powerful to meet their needs and will often allow users to add custom creation methods e.g. Jacksons @JsonFactory. 3. Users who mix regular and cucumber expressions may run into conflicts when a registered cucumber expression and unregistered happens to collide. However this was the situation before this flag was added. 4. Regular expression users who define custom parameter types do so with the expectation that the parameter will be matched. Subverting this expectation when the method signature does not match may result in a parameter transformer that is unable to convert to the desired type. Leaving the user puzzled as to why his transform was ignored. Fixes: #658
* cucumber-expressions: Prefer Java type hint over parameter type When there is a conflict between the type hint from the regular expression and the method prefer the the parameter type associated with the regular expression. This ensures we will use the internal/user registered parameter transformer rather then the default. Unless the parameter type indicates it is the stronger type hint. Reasoning: 1. Pure cucumber expression users will not notice this in either scenario. 2. Pure regular expression users will benefit because `BuiltInParameterTransformer` can now seamlessly transform any captured values. (For all built in types useRegexpMatchAsStrongTypeHint is explicitly set to false.) 2. Regular expression users that define a default transformer have little need to define parameter types. The default transformer should be sufficiently powerful to meet their needs and will often allow users to add custom creation methods e.g. Jacksons @JsonFactory. 3. Users who mix regular and cucumber expressions may run into conflicts when a registered cucumber expression and unregistered happens to collide. However this was the situation before this flag was added. 4. Regular expression users who define custom parameter types do so with the expectation that the parameter will be matched. Subverting this expectation when the method signature does not match may result in a parameter transformer that is unable to convert to the desired type. Leaving the user puzzled as to why his transform was ignored. Fixes: #658 * cucumber-expressions: Prefer Go type hint over parameter type When there is a conflict between the type hint from the regular expression and the method prefer the the parameter type associated with the regular expression. This ensures we will use the internal/user registered parameter transformer rather then the default. Unless the parameter type indicates it is the stronger type hint. Reasoning: 1. Pure cucumber expression users will not notice this in either scenario. 2. Pure regular expression users will benefit because `BuiltInParameterTransformer` can now seamlessly transform any captured values. (For all built in types `useRegexpMatchAsStrongTypeHint` is explicitly set to false.) 2. Regular expression users that define a default transformer have little need to define parameter types. The default transformer should be sufficiently powerful to meet their needs and will often allow users to add custom creation methods e.g. Jacksons @JsonFactory. 3. Users who mix regular and cucumber expressions may run into conflicts when a registered cucumber expression and unregistered happens to collide. However this was the situation before this flag was added. 4. Regular expression users who define custom parameter types do so with the expectation that the parameter will be matched. Subverting this expectation when the method signature does not match may result in a parameter transformer that is unable to convert to the desired type. Leaving the user puzzled as to why his transform was ignored.
Summary
The compatibility with previous version(s) is broken.
A step definition that uses
(\d+)capture group forces the method have anInteger(orint) argument. Previously aStringwould do fine.Example code:
Expected Behavior
The typed value is converted into a
String, just like it was previously (tested with info.cukes.cucumber-java v1.2.5)Current Behavior
An exception is thrown:
Context & Motivation
This is particularly bad since it would try to convert whatever is given, for example, providing
2222222222(which is too big for an Integer) results in:Your Environment
The text was updated successfully, but these errors were encountered: