Incorrect extracting of {string}

[DDtKey]

In accordance with cucumber-expressions - {string} should return only text between quotes.

Parameter Type	Description
{string}	Matches single-quoted or double-quoted strings, for example "banana split" or 'banana split' (but not banana split). Only the text between the quotes will be extracted. The quotes themselves are discarded. Empty pairs of quotes are valid and will be matched and passed to step code as empty strings.

But in current version there are quotes in String value

[ilslv]

@tyranron the trouble with this issue is that inside cucumber crate we map regex capturing groups one to one into callback parameters.

#[given(expr = "{param1} {param2} {param3}")]
fn callback(param1: i32, param2: i32, param3: i32) { ... }

So every parameter has to be represented with single capturing group and in case group didn't match we return empty string to avoid messing up the order.

We have to provide regex, that will match both "text" and 'text' into single group containing text and I don't think this is possible with regex crate, as it would require remembering starting quote and matching until we find the same one.

Possible solutions to this issue

1. Return 2 groups with special names. Only 1 of them will match and handle another one inside cucumber crate based on a special name.
2. Require users to always escape " inside '...' and vice versa.
3. Leave it as is.

I like option 2 the most, because it simplifies the matching group, while not contradicting existing vague description of the language. But to be fair actual implementation returns group containing 3 capturing groups: ("([^"\\]*(\\.[^"\\]*)*)"|'([^'\\]*(\\.[^'\\]*)*)') and " ' " is completely valid parameter.

In case of Java, they are handling strings as some kind of special way from what I can tell. This is the only parameter consisting of 2 separate regex groups.

[tyranron]

@ilslv thank you for the clear explanation.

We cannot deviate much from what official implementation does, so the option 2 is not an option, unfortunately.

So, as the Java implementation does, we should handle {string} in a special way too on the cucumber side. Either with matching 2 capturing groups (as you've described), or by matching the whole, including quotes (as we do now), following by some post-procession (trimming quotes) in machinery before feeding it into the function.

[tyranron]

@DDtKey this is fixed now in 0.12.0 cucumber release.

Additionally, we have extended this case to custom parameters as well. So now, similar patterns where multiple capturing groups are required may be used for them too.

[DDtKey]

Thanks for the quick update! 💥