Parameter count mismatch on optional parameter after migrating from SpecFlow

[BalazsSzaboElypta]

Reqnroll Version

2.0.3

Which test runner are you using?

MSTest

Test Runner Version Number

3.3.1

.NET Implementation

.NET 8.0

Test Execution Method

Visual Studio Test Explorer

Content of reqnroll.json configuration file

No response

Issue Description

Before migrating to Reqnroll from Specflow a step definition using a regular expression with optional parameter (see example below) used to be working, but after migrating I get Reqnroll.BindingException: Parameter count mismatch! error if I don't provide the optional parameter.

I didn't find any breaking change related to this in the migration documentation, so I'd expect it to be working the same (i.e. for the option parameter to be null if I don't provide a value for it in the feature file)

Steps to Reproduce

Use this step definition:

[StepDefinition(@"^Do something (\d+) times(?: as user '(.+)')?$")]
public void DoSomething(string times, string userString)
{
    string user = userString ?? "defaultUser";

    handleDoSomething(times, user);
}

And these test cases:

# Throws Reqnroll.BindingException: Parameter count mismatch!
Scenario: Test
    When Do something 5 times

# Executes fine
Scenario: Test2
    When Do something 5 times as user 'user1'

Link to Repro Project

No response

[gasparnagy]

@BalazsSzaboElypta Wow, that is strange. Regarding my knowledge we never (officially) supported optional parameters with SpecFlow so I think it was just a lucky coincidence that that was working. Which version of SpecFlow you are migrating from?

[BalazsSzaboElypta]

From 3.9.74 so I guess it's possible that it's a breaking change from V3 -> V4

[gasparnagy]

Probably. But as I said, this was just working accidentally, so it was not a goal to keep it. Do you have many of them? Would it be possible to refactor them to ones without optional parameters?

Because to be honest a proper support for that is not super easy and we anyway migrate people from regex to cucumber expressions (where such thing is not even possible), so implementing a support for optional parameters is not a strategic goal right now.

[BalazsSzaboElypta]

I understand, we have around a dozen or two, so it's not the end of the world to refactor them. Probably would make the code a bit more readably as well since the regex expressions tend to get a bit complex with a lot of optional parameters.

Thanks for the clarification!

[gasparnagy]

@BalazsSzaboElypta thx for the understanding. Yes, one of the motivation behind the whole cucumber expression initiative was (by the cucumber community), that the regexes could become quite complex and therefore harder to maintain.

I close this issue now, but if anything comes up, feel free to reopen.