Cucumber expressions in StepArgumentTransformation expression

[MaxGuernseyIII]

I tend to lean on sophisticated graphs of step argument transformations.

Consider the following line:

Given line item [I] is per quantity [Q] of unit [U]

At the statement level, this is easy to automate with an expression like Given {LineItem} is per {Amount}

The problem comes when I want to automate the step argument transformation for the amount fixture.

I have many different ways that I can express a quantity. I would like all of them to apply in the "quantity of unit" pattern. I have fewer ways to express a unit, but I would still like them all to apply.

To accomplish this right now, I either have to write a regex that captures all the possible shapes of {Quantity} or settle for something like (.*).

The former is unsustainable because I must duplicate and maintain the graph of possible expressions. For large, complicated step arguments, this is odious.

The latter casts a wide enough net that it frequently confuses the highlighter and sometimes confuses the actual engine. I often find myself doing this, living with the red underlines, and cleverly disambiguating when actual overlap impacts the test run (admittedly infrequently).

It would be much easier and cleaner if I could write a step argument transformation with the pattern {Quantity} of {Unit} and then get all the parsing and pattern-generation logic that applies at the step level for free.

If this is something that is already implemented, my apologies, I cannot find it.

If this is something that could easily be done as a plugin, I will happily write it.

If this is something that involves a core change, (which I suspect it is), I'll gladly generate the PR.

...but first it seems worth talking about.

[gasparnagy]

Do I understand right, that basically what you would like to have is to be "able to use Cucumber expressions for step argument transformations, with the ability to use custom parameter references in them that are resolved by another step argument transformations", correct?

[MaxGuernseyIII]

Ahhh. I see. It's the potential for different expression behavior in different Reqnroll versions needing to be coordinated that presents the challenge. Hmm. Honestly, I'd live with the weird extra red underlines and not feel too bad about it. That's cosmetic.

When the tests are running, though, that's function. I still believe a single abstraction that hides everything (and that could be an extension point so someone could do something like put in an ANTLR mini parser) is the best way to go, moving forward.

But that's just my opinion.

[gasparnagy]

Honestly, I'd live with the weird extra red underlines and not feel too bad about it. That's cosmetic.

We have currently 9 open issues for the incorrect VS extension handling... So it seems that you (and myself) are not necessarily representing the average.

When the tests are running, though, that's function. I still believe a single abstraction that hides everything (and that could be an extension point so someone could do something like put in an ANTLR mini parser) is the best way to go, moving forward.

If there would be no VS extension, I would fully agree. But in this context the situation is somewhat different... 🙁

What we could do though is to create an abstraction that represents the matching of an "expression" and optionally also provides a regex. The runtime could do the matching via the abstraction and the VS extension would receive the regex. For custom/special usage, like yours, you could decide to not provide a regex (then this special ones would not be supported in VS) or provide a simplified "good enough" regex that is enough for VS extension even if not fully correct. What do you think? (This would be along the route of your option 3 mentioned earlier.)

[MaxGuernseyIII]

I'm still confused about why we can't just provide this data structure to the plugin instead of regex. That said, I can easily add a Visitor to LineParser it and a ToRegex visitor that generates a simplified regex - one that will always match what the underlying patter matches, but maybe also match more.

That said, I still don't understand why we cannot use LineParser's Matcher<> in place of Regex. It supports regex as one of the underlying Pattern<>s a Matcher<> can be stringified to JSON easily and rematerialized almost as easily. The library is in .NET Standard 2.0, so compatibility oughtn't be an issue.

Looking at the 9 issues you cited, those all appear to have something to do with assembly loading. I do not understand the connection between that and needing to couple to regex instead of some other abstraction for pattern matching.

Anyway, if making it work in the runner and providing simplified regexes for the IDE plugin is a real possability, let me know and I'll make the appropriate changes to LineParser.

Thanks.

[MaxGuernseyIII]

What about PCRE.NET? It's less portable than LineParser but it should still work in IDEs, on desktops, and on build servers. It would allow you to generate a single "(?(DEFINE))" block that you append to all regular expressions. You can use a stable naming convention for all your definitions and just replace "{ParameterName}" with "(?&ParameterName)". Since the parsing and already works recursively (as proved by when I use "(.*)" or embed one pattern in another), this would solve the problem completely. It could even be proposed to the cucumber expression folks as a core feature, since PCRE appears to be supported natively in a lot of places.

I still believe I have created the right abstraction for this process. The fact that there are two languages in use means there is a concept that varies and I have encapsulated that concept with LineParser.

But if there really is a reason that the system must be coupled to regex strings (which I still do not comprehend), PCRE.NET and clever parsing could solve this problem relatively cleanly...

[MaxGuernseyIII]

I added the ability to get a simplified regex and the ability to serialize to and from strings to LineParser. So it could serve as a viable .NET standard 2.0 (fully portable) replacement/encapsulation for regex.

[Code-Grump]

I would like to add that I think I've encountered this scenario on every BDD project I've worked on, usually for dates:

Given a thing happened yesterday
Given a thing happened 5 minutes ago
Given a thing happened 9 hours and 30 minutes ago

Conceptually we're looking at one step which accepts a relative expression of a point in time: we want a {RelativeDate} expression associated with a transform that can give us an instant in time and then pass that instant to the step.

I typically have worked to the platform's strengths and produced a step definition for every variation, if for no other reason than to get the auto-complete suggestions available for my team to follow. The steps revert to taking primitives and we do the conversion within the step itself, not an argument transform.

[Given("a thing happened {int} days and {int} hours ago")]
public void GivenAThingHappenedDaysAndHoursAgo(int days, int hours)
{
    ...
}

It means I have to produce a bunch of steps that I'd rather not have to write, and it explodes if there are multiple date-related conceptual steps that all need variations but they are simple at least.

[gasparnagy]

Guys, I see that you have a lot in your minds, but I fear I can't follow you or maybe we turned this into an XY problem. Could we just go back to basics and could you please explain the source problem?

You have listed two cases:

Given a thing happened yesterday
Given a thing happened 5 minutes ago
Given a thing happened 9 hours and 30 minutes ago

and

And item [I] has stock level [C] + [T] - 1
And item [I] has stock level [C] + the low inventory threshold - 1

Both seem to be instances of a higher level domain abstraction (relative time, or formula) expressed in Gherkin. So far I understand.

The canonical solution for this would be to represent these with some type and a step argument transformation. Assuming you have a RelativeDate (or even DateTime directly) and StockFormula types, you can create a step argument transformation for with them:

[StepArgumentTransformation("(.*?)")
public RelativeDate ConvertRelativeDate(string relDateExpression) { /*magic*/ }

so that you can use step definitions, like this one, no need to make combinations for the Given step definitions.

[Given("a thing happened {RelativeDate}")]
public void GivenAThingHappened(RelativeDate when) { ... }

Reqnroll can give a little help on making the /*magic*/ simpler and allow basic pattern matching, but this is optional:

[StepArgumentTransformation("yesterday")
public RelativeDate ConvertRelativeDate(string relDateExpression) { return <yesterday>; }

[StepArgumentTransformation("(\d+) minutes ago")
public RelativeDate ConvertRelativeDate(int minutes) { return <now - minutes>; }

[StepArgumentTransformation("(\d+) hours and (\d+) minutes ago")
public RelativeDate ConvertRelativeDate(int hourse, int minutes) { return <now - hours and minutes>; }

The same with the stock formula: the formula can be parsed with any special parser at the point of /*magic*/.

Having this starting point. How would you like to improve the system from the usage perspective?

[Code-Grump]

I have tried this solution too. I found the lack of autocomplete support (seeing what types of relative date were valid) made it unpalatable to feature authors.

But my example was simply to illustrate that whilst it's possible to create complex expressions that utilise transformations, this may be an case were doing the "verbose but simple" thing might be the better path.

[gasparnagy]

I have tried this solution too. I found the lack of autocomplete support (seeing what types of relative date were valid) made it unpalatable to feature authors.

But my example was simply to illustrate that whilst it's possible to create complex expressions that utilise transformations, this may be an case were doing the "verbose but simple" thing might be the better path.

I understand. Solving the autocomplete issue is an easier problem, as that does not need to be 100% accurate. I think if we would make the autocomplete in a way that it "learns" from the existing feature files (i.e. what the user has used in feature files for parameter of that given or at the position of a {RelativeDate}), we could improve the user experience quite much.

[MaxGuernseyIII]

Okay. If you want to say that what I said was an "XY problem", I will accept that and restate at the proper level of abstraction.

Here is the real problem:

I need to be able to define step arguments with rich, potentially recursive inner syntax and structure.

Examples of such problems include, but are not limited to:

• expression syntaxes (e.g., formulae)
• list operation syntaxes (e.g., comma delimited, spread operators)

I need to do this with zero redundancy of definition while giving Reqnroll's execution and IDE engines a complete, perfect understanding of the structure so that two possible interpretations that should not overlap are not treated as overlapping because I was forced to use (.*).

I would like for that structure to be navigable by the IDE to support autocomplete, but that's not essential.

[gasparnagy]

OK. So basically you would like to have an embedded DSL into the Cucumber expressions. That makes sense.

What I would like to analyze further is that your expectation of "giving Reqnroll's execution and IDE engines a complete, perfect understanding of the structure so that two possible interpretations [...]" mean. Let's try to find a concrete example of two possible interpretations and let's compare the expected behavior versus the behavior you have with (.*) right now. Do you have such an example that we could look at?

[MaxGuernseyIII]

Sure. Imagine you want to parse the string "A + B * C", but elsewhere you have "B * C + A". Still elsewhere you have "B * (A + C)" and "(A+B)*C". And so on. If you match the patterns "(\w+)\s*\+\s*(.*)" and "(\w+)\s*\*\s*(\w+)", you get lucky on the first one. To bring in the second string, you have to get much more complex. And so on. Furthermore the first pattern also matches strings like "A+ students are the best students", then gives a poor explanation for why the second half of the string can't be converted to whatever those expressions are supposed to mean. If I push the problem down to ANTLR and just take expressions as (.*), then I end up matching and kind of grammatical error and getting it highlighted as a valid expression, only finding out it's not when I run the tests and get a stack trace. With the ability to make Reqnroll aware of "minor grammars", I don't have any of those problems. I can express each relationship appropriately. I can use precedence to prefer the right one. Most importantly, I don't have to accept false matches as part of the cost of doing business. Also there is the issue that right now the mappings from one STA to another are by type and not name, creating an asymmetry between how parsing works at the expression and argument level. That can go away, too.

…

-- Max blog.abiding.software

On Thu, Jan 29, 2026, 2:59 AM Gáspár Nagy ***@***.***> wrote: OK. So basically you would like to have an embedded DSL into the Cucumber expressions. That makes sense. What I would like to analyze further is that your expectation of "giving Reqnroll's execution and IDE engines a complete, perfect understanding of the structure so that two possible interpretations [...]" mean. Let's try to find a concrete example of two possible interpretations and let's compare the expected behavior versus the behavior you have with (.*) right now. Do you have such an example that we could look at? — Reply to this email directly, view it on GitHub <#986 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4DRFTHRZR6KQNP7U2C6JD4JHRYVAVCNFSM6AAAAACQ3RBREKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRTHEYDOMA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gasparnagy]

Thx, I still not get the example.

I would like to focus on full steps, because this is the only way we can evaluate this in full context.

So let's say we have a .NET type called CustomExpression that we use to represent expressions like A + B * C or (A+B)*C.

Let's look at the step you have mentioned.

Given A+ students are the best students

In this step, "A+" is not an expression, but a grade, so the step definition would be:

[Given("{Grade} students are the best students")]
public void StudentsAreTheBest(Grade grade){...}

This will only accept Grade as text before students are the best, so it does not matter what step argument transformation you have configured for CustomExpression, because Reqnroll will only consider the ones that are related to the expected type (Grade in this case). So there is no collision even if you register CustomExpression with (.*)

A more complicated example would be.

Given the performance of the students are calculated with formula A + B * C for the year

Here the problem could be whether "for" is part of the expression or the step text.

However the logic of step matching in Reqnroll solves this.

Assuming you define your step definition and step arg conv as:

[Given("the performance of the students are calculated with formula {CustomExpression} for the year")]
public void GivenXXX(CustomExpression expression) { ... }

[StepArgumentTransformation("(.*)")]
public CustomExpression ConvertExpression(string expression) {
   // use ANTLR or any custom parser to parse expression to CustomExpression 
}

Again, there is no collision, because the final regex that Reqnroll internally calculate will be ^the performance of the students are calculated with formula (.*) for the year$ so it strips out A + B * C from the text (and not the for!) and passes it to the step argument transformation.

Do you have a full step example where you do see an actual problem with the (.*) matching for custom embedded expressions?

[MaxGuernseyIII]

Cucumber Expressions Then: {StringFixture} = {StringFixture} Then: {NumberFixture} = {NumberFixture} Step Arguments StringFixture: string (\[[\w\d_]\]) StringFixture: "((?:[^"]|"")*)" StringFixture: (.*) \+ (.*) NumberFixture: number (\[[\w\d_]\]) NumberFixture: (\d+) NumberFixture: (.*) \+ (.*) Now you either get overlap for the statement "Then string [x] + string [y] = string [a] + string [b]" or you have to replicate the other expressions in place of .*. I run into this every time I build a project using something like Cucumber or Reqnroll. Often, I give up and just train the stakeholders to read Gherkin in C#. This time, I'm trying to break through.

…

-- Max

On Mon, Feb 2, 2026, 2:56 AM Gáspár Nagy ***@***.***> wrote: Thx, I still not get the example. I would like to focus on full steps, because this is the only way we can evaluate this in full context. So let's say we have a .NET type called CustomExpression that we use to represent expressions like A + B * C or (A+B)*C. Let's look at the step you have mentioned. Given A+ students are the best students In this step, "A+" is not an expression, but a grade, so the step definition would be: [Given("{Grade} students are the best students")] public void StudentsAreTheBest(Grade grade){...} This will only accept Grade as text before students are the best, so it does not matter what step argument transformation you have configured for CustomExpression, because Reqnroll will only consider the ones that are related to the expected type (Grade in this case). So *there is no collision* even if you register CustomExpression with (.*) A more complicated example would be. Given the performance of the students are calculated with formula A + B * C for the year Here the problem could be whether "for" is part of the expression or the step text. However the logic of step matching in Reqnroll solves this. Assuming you define your step definition and step arg conv as: [Given("the performance of the students are calculated with formula {CustomExpression} for the year")] public void GivenXXX(CustomExpression expression) { ... } [StepArgumentTransformation("(.*)")] public CustomExpression ConvertExpression(string expression) { // use ANTLR or any custom parser to parse expression to CustomExpression } Again, *there is no collision*, because the final regex that Reqnroll internally calculate will be ^the performance of the students are calculated with formula (.*) for the year$ so it strips out A + B * C from the text (and not the for!) and passes it to the step argument transformation. Do you have a full step example where you do see an actual problem with the (.*) matching for custom embedded expressions? — Reply to this email directly, view it on GitHub <#986 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4DRFS7HIPWHJTQPGSJCP34J4UMZAVCNFSM6AAAAACQ3RBREKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRXGEZTSNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gasparnagy]

Sorry. I feel really doomed. Could you please make concrete step examples? I cannot decode your notations.

[MaxGuernseyIII]

Okay. Here is a working* demo of what I mean.

https://github.com/MaxGuernseyIII/ReqnrollOverlapDemo

As you can see, each of the scenarios runs until the final statement. That is because the "string" and "number" parts of the named-variable patterns are enough to break ambiguity and, of course, string literals are shaped very differently from numerical literals.

Yet, even though the terminal elements are sufficient to break ambiguity, when they are composed via (.*), the ambiguity-breaking specificity is obliterated. As a result, without something like LineParser or PCRE, Reqnroll cannot tell the difference between the the lines that end each of the two scenarios.

You can. I can. A compiler with a little more information can. Just not Reqnroll.

To solve this problem, today, everything that is defined about each of the terminals and each of the nonterminal expressions must be encoded where the (.*)s go. This ranges somewhere from a massive nuisance to completely impractical, depending on the complexity and recursion of the potential expression.

Pushing it down to "magic" and using ANTLR or whatever underneath the (.*)s will not help, because the (.*)s are the problem.

Does this clarify?

*: By "working", I mean it is broken in the way I am trying to convey.

[MaxGuernseyIII]

@gasparnagy Were you able to look at the example repo I gave you?