Support of method name underscores dropped?

[HHobeck]

Hi there.

Does reqnroll support method-name-underscores?

https://docs.specflow.org/projects/specflow/en/latest/Bindings/Step-Definitions.html#method-name-underscores

If not are there any reason not supporting it?

Regards
Hardy

[gasparnagy]

As far as I see, it was not removed from the code, just not included in the documentation. So I think it should work. You can set MethodNameUnderscores or MethodNamePascalCase to this config, but the existing step definitions with underscores should work even without this config.

But I'm just saying this by looking at the code, haven't tried it. Could you please try.

In general: I think my original motivation of not including it to the documentation was to deprecate this feature in long term (or at least do not encourage new users to use it). I really liked this style, but it never worked perfectly so I often had to switch back to regex. Having multiple step def styles makes the IDE support (like VS) more complex, so I thought deprecating these might be a good simplification in long term.

But I am not fully settled on this, we can have a discussion about it. How do you use this feature, what are the benefits of it for you in compare to regex or even more cucumber expressions.

[HHobeck]

Yes you are right it is working like expected. Don't know why it doesn't the first time. Anyway you are asking me about the motivation, why I'm using this feature: It is because I don't need to write the expression twice and the methods are more readable when using the underscores.

May I ask you to give me some examples where it will be problematic or error prone using this style? I don't see any reasons why to deprecate it.

[gasparnagy]

May I ask you to give me some examples where it will be problematic or error prone using this style?

They were related to param handling. These are my notes from an old code, but I haven't re-validate them:

• If the parameter contained a leading @, [ or #, like Given the param is "@foo", the @ was not passed (maybe only when the param is at the end)
• The closing quote or apostrophe is passed to the parameter if the parameter is at the end: Given the param is "foo", the passed value is foo"

[gasparnagy]

I don't see any reasons why to deprecate it.

Keeping the support for it does not cost much, so from that perspective you are right (although there are still some bugs in it as I mentioned in my previous comments).

The problem is more the IDE integration. The VS integration "understands" this syntax, but some features (e.g. rename step) is not available. VSCode (with Cucumber plugin) does not even understand this syntax and as far as I know also Rider does not work with this syntax. When we provide this option to the users, they will implicitly assume that it works with all IDE. I guess you use VS right now, but maybe later you will have a colleague who would like to use Rider or VSCode and they will be upset that it does not work with their tool (ie they will not be able to navigate to the step definitions). We could of course add support for this into these projects, but with out current capacity this is not very likely to happen.

So normally we should only have features that we can support all across our integration possibilities and in general it is better to not have a feature than a half-working feature.

But as I said, the problem is really on the IDE integration side, in Reqnroll itself keeping it as it is does not cost much, so I don't think we will ever "remove" this feature.

Maybe what we should do is to include these options to the docs with the warning of limited IDE support... Have you been aware (affected) by these limitations? Where in the documentation would you expect to explain these?

If you feel energy to fix those functional issues I mentioned (maybe you have also found a few), it would be great if you could help fixing them. The related code is quite isolated (implemented in StepDefinitionRegexCalculator class) and has a bunch of unit tests already (StepDefinitionRegexCalculatorTests class), so it is relative easy to get started with it.

[HHobeck]

So normally we should only have features that we can support all across our integration possibilities and in general it is better to not have a feature than a half-working feature.

Thank you for explaining this.

Maybe what we should do is to include these options to the docs with the warning of limited IDE support... Have you been aware (affected) by these limitations?

The only thing I have noticed is in VS 2022 that the intellisense is not working properly. The method name is used with underscores instead of the well-known gherkin syntax.

Where in the documentation would you expect to explain these?

I would say this location might be good:
Setup an IDE for Reqnroll -> Installation & Setup -> Setup Visual Studio 2022

If you feel energy to fix those functional issues I mentioned (maybe you have also found a few), it would be great if you could help fixing them. The related code is quite isolated (implemented in StepDefinitionRegexCalculator class) and has a bunch of unit tests already (StepDefinitionRegexCalculatorTests class), so it is relative easy to get started with it.

Yes no problem. If I see something which I can fix, I'll create a PR. Thank you for your work.

[gasparnagy]

The only thing I have noticed is in VS 2022 that the intellisense is not working properly. The method name is used with underscores instead of the well-known gherkin syntax.

Ah yes. We have a Gherkin->underscored method name conversion logic, but not a backwards one. So the intellisense cannot provide a nice suggestion. I don't know how hard would it be to implement a backwards conversion logic though.