Proposal for deprecations in v4 (removal in v5)

[gasparnagy]

We will start planning v4 soon. For that I started to draft a list of things that I would consider to deprecate. This would mean that using these features will be still possible in v4, but they will show warnings. They would be then removed in v5.

This is an open list. If you have any other suggestion (things that cause maintenance issues, but not broadly used), or have problems with any of the proposals in this list, please hare it. Made the most impacting ones bold.

• VB test projects: use by only 0.02% of the projects and easy to workaround by moving the VB step definitions to a class library that is then used by a C# Reqnroll project

• SpecFlowCompatibility package: time to remove the training wheels

• SpecFlow compatibility "Action" packages in https://github.com/reqnroll/Reqnroll.Actions: these are not maintained actively anyway

• Table class: the DataTable class is a better aligned with the syntax terminology of Gherkin

• Subclassing Given/When/Then/StepDefinition attributes: would make code-based the discovery for the default case easier. One can still use project-level aliases or custom attributes/plugins if that customization is needed.

• Method-name-based expression matching, like [Given]: It was a nice idea, but was never really picked up and the implementation is still buggy.

• Only allow stepdef/hook/step-arg-conv attribuets in class that have [Binding] attribute directly and do not allow [Binding] attribute on a class that have a [Binding] attribute in any of the base classes. (So basically let people treat binding classes as sealed.): Not following these guidenlines is anyway causing different issues (see my post), and enforcing these rules could be a first step for eventually getting rid of the [Binding] attribute if we want. Also this makes the code-based discovery much easier, like the deny of subclassing G/W/T above.

• Configuration related deprecations:

  • Old SpecFlow compatible config options that have been renamed, e.g. stepAssemblies
  • Old options that are kept, but not included in the documentation (for a good reason) e.g. runtime/dependencies, trace/traceTimings, etc.
  • Remove runtime/obsoleteBehavior config: I can't imagine a good use-case of it and have never seen it used
  • Remove runtime/missingOrPendingStepsOutcome config: This setting is not really effective anyway, because the test frameworks anyway need to map this to their specific outcome, if possible.

• Internal API:

  • ITestThreadExecutionEventPublisher: there is no point having this test-thread specific, should be replaced by an event test run based

• Not sure, but to consider:

  • Move generation-related config settings to MsBuild, and keep only runtime settings in reqnroll.json config (i.e. only things that can be effectively changed without the need to recompile the project, or with other words: the compilation should not need to load the reqnroll.json config): This would simplify our build process and would be more aligned with the patterns used by other tools.
  • Consider renaming [StepArgumentTransformation] attribute to [ParameterType]: Better alignment to Cucumber terminology
  • Deprecate the [Binding] attribute generally. The presence of one of the actual "binding" attributes (G/W/T, hooks, step-arg-conv) should be the indicator of intent.

[Code-Grump]

I would like to deprecate the Binding attribute generally. The presence of one of the actual "binding" attributes should be the indicator of intent. I might look at pulling together a PR for this if there's an appetite for including it in v4.

[gasparnagy]

Makes sense. Added it to the list. I have added it to the "consider" section, because we need to check carefully if there is anything that would be blocked by the removal of it, but I cannot think of anything right now.

[gasparnagy]

If you could make a draft PR for this (i.e. use the "binding" attributes as indicator of intent, not the [Binding] attribte), we could check it against a few real-life Reqnroll projects to find any inconsistences that we did not think of.

[Code-Grump]

PR for this change #1044

It will need documentation changes that I haven't performed yet, plus I'd expect to make changes to our IDE plugins to no longer emit the redundant attribute. I have held off on attempting these until we're happy with this foundational work first.

[304NotModified]

Won't this make the type scanning slow? And maybe also less robust? (Checking every method could create easier typeload issues)

[Code-Grump]

If you have thoughts, I'd ask you put them on the PR itself; it feels like a more natural place to discuss whether it's a change we want to make.

[304NotModified]

Only allow stepdef/hook/step-arg-conv attribuets in class that have [Binding] attribute directly and do not allow [Binding] attribute on a class that have a [Binding] attribute in any of the base classes. (So basically let people treat binding classes as sealed.)

I think I have an use case which uses this (not recommended) approach. I will try to give more details this week.

[304NotModified]

I checked the code, but I see it's already sealed :)

This is the case, a generic library to connect Reqnroll with Playwright

[Binding]
public sealed class ReqnrollPlaywrightIntegration(IScenarioLogger scenarioLogger)
{

    [BeforeScenario]
    public async Task BeforeScenario()
    {
       // Start Browser, Create Page etc
    }

    [AfterScenario]
    public async Task AfterScenario()
    {
        // Stop Browser, Dispose Page etc
    }

}

At first I was thinking you would like to subclass this to change behavior of the Create Page etc. But another option is to inject this behavior with DI. Just like the IScenarioLogger scenarioLogger in the above example.

[gasparnagy]

Yes, this is the right way to do (injecting the logger that you want to share).

[clrudolphi]

Should we consider retirement of any of the Connectors in the VS Extension project?

[gasparnagy]

We can, but let's put it to a separate roadmap discussion for the Visual Studio extension. Let's keep this thread focus only about the framework updates.

[clrudolphi]

You mention retirement of Reqnroll.SpecFlowCompatibility.Actions.*; but Reqnroll.Actions has not been successfully built in 10 months. Is the entire Actions package ready for deprecation?

If we want to keep it, then it needs some love, including a fix for the Html Calculator test which needs a static page hosted somewhere (like on reqnroll.net).

[gasparnagy]

I think I wasn't clear enough, but I meant the same: deprecate the entire Reqnroll.Actions repo.

If we want to keep it, then it needs some love, including a fix for the Html Calculator test which needs a static page hosted somewhere (like on reqnroll.net).

I would like to see such how-to examples more as part of contributions of individuals (e.g. in a form of a personal sample repo + blog post). I would be happy to host or reshare the blog post on reqnroll.net, but keep maintaining of these (by nature opinionated) samples is not something we should take on our shoulder imho.