Add a reqnroll config option to not consider cucumber expressions

[jdb0123]

Currently regex expressions incorrectly determined as cucumber expressions can be fixed by appending ^ and $ to the start and the end of the expression. This extra configuration aims to make it easier to only use regex expressions without having to append ^ and $.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue).
• [x] New feature (non-breaking change which adds functionality).
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
• [ ] Performance improvement
• [ ] Refactoring (so no functional change)
• [ ] Other (docs, build config, etc)

Checklist:

• [x] I've added tests for my code. (most of the time mandatory)
• [ ] I have added an entry to the changelog. (mandatory)
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly. --> The website has not yet been updated https://docs.reqnroll.net/latest/automation/cucumber-expressions.html

[gasparnagy]

@jdb0123 Thx for considering this. I'm absolutely understand the frustration you might have with the incorrect detection of regexes, but I'm not sure we should introduce a config setting to globally disable this, for multiple reasons:

• This is a one-time problem and only for existing projects and it can be easily fix by adding the ^ and $ markers. I have even provided a simple solution that can be used for changing all of them with a single search and replace in Visual Studio. (See docs.)
• With such a global setting we would block users from iteratively moving on to Cucumber Expressions, that are now the "industry standard".
• This adds a certain complexity and maintenance overhead on the codebase of the IDE integrations. We would need to update this in the Visual Studio extension (making sure we found the right config, testing, etc.) but also for example the Visual Studio Code extension would not be compatible with that.

[jdb0123]

Hi @gasparnagy thanks for the quick reply.

This is a one-time problem and only for existing projects and it can be easily fix by adding the ^ and $ markers. I have even provided a simple solution that can be used for changing all of them with a single search and replace in Visual Studio. (See docs.)

We run into this multiple times. We have quite a large repo of steps, all in regex structure. When steps are updated, they can become ambiguous between a cucumber or regex step. Which is only detected during runtime.

With such a global setting we would block users from iteratively moving on to Cucumber Expressions, that are now the "industry standard".

I think it would mainly enable people to make to keep using regex expressions. When they desire to (iteratively) move to cucumber expression, they can still use the ^ and $ markers to specifically mark their regex expressions (as described by you above). Which can then be slowly replaced by cucumber expressions. We would like to keep using regex expressions over cucumber expressions, due to their flexibility and since we have quite a large amount of "static analysis" test for our regex expressions.

This adds a certain complexity and maintenance overhead on the codebase of the IDE integrations. We would need to update this in the Visual Studio extension (making sure we found the right config, testing, etc.) but also for example the Visual Studio Code extension would not be compatible with that.

Could you explain which changes would be required in the extensions order to support this? Currently the only thing I could think off is the skeleton snippets. I would be more than happy to assist on making the required changes to the IDE extensions.

[gasparnagy]

I have made some tests with an alternative solution. If you update to Reqnroll v2.0.0, you can add a simple in-project plugin to your solution where you can reconfigure the cucumber expression detection. You can fine-tune the rules or even completely disable cucumber expressions. I have tested and it seemed to work. Could you please give it a try and let me know if that would be sufficient? If yes, I would add this to the docs.

So the only need to add this file to your Reqnroll project:

using Reqnroll.Bindings.CucumberExpressions;
using Reqnroll.Plugins;
using Reqnroll.UnitTestProvider;
using ReqnrollCalculator.Specs.Support;

[assembly:RuntimePlugin(typeof(ForceRegexPlugin))]

namespace ReqnrollCalculator.Specs.Support;

public class ForceRegexPlugin : IRuntimePlugin
{
    // ReSharper disable once ClassNeverInstantiated.Local
    private class ForceRegexDetector : ICucumberExpressionDetector
    {
        public bool IsCucumberExpression(string cucumberExpressionCandidate)
        {
            return false;
        }
    }

    public void Initialize(RuntimePluginEvents runtimePluginEvents, RuntimePluginParameters runtimePluginParameters, UnitTestProviderConfiguration unitTestProviderConfiguration)
    {
        runtimePluginEvents.CustomizeGlobalDependencies += (_, args) =>
        {
            args.ObjectContainer.RegisterTypeAs<ForceRegexDetector, ICucumberExpressionDetector>();
        };
    }
}

[jdb0123]

Hi @gasparnagy

That appears to be an elegant solution and effectively addresses our issues. I've tested it by integrating it directly into the bdd project. And also tested it by creating a separate plugin project, which is then added a reference to the bdd project. Both work as expected.

Thank you for providing an alternative solution. I would suggest to close this PR.

[gasparnagy]

@jdb0123 Super. Thx for the feedback. I keep this open for myself as a reminder to add this to the docs, but I will close it after.

[gasparnagy]

Workaround documented at https://docs.reqnroll.net/latest/guides/how-to-configure-cucumber-expression-behavior.html

[jdb0123]

@gasparnagy Very minor:

In order to override the detection strategy, you need to implement a simle --> simple Reqnroll runtime plugin. In the simplest case this is just adding a C# file to your Reqnroll project.

Besides that it seems like clear documentation :+1:

[gasparnagy]

@jdb0123 Thx for checking. Fixed the typo.