Feature Define Step Command generates async step definition methods

[clrudolphi]

🤔 What's changed?

Enhanced the Define Steps command to support generating method stubs that are async.
This honors the reqnroll.json Trace setting introduced in Reqnroll PR#876.
The DefineStep dialog box now has a check box to indicate whether to use async methods.

⚡️ What's your motivation?

Developer productivity by eliminating the need to edit the generated stubs to support async.

🏷️ What kind of change is this?

• ⚡ New feature (non-breaking change which adds new behaviour)

♻️ Anything particular you want feedback on?

Haven't changed any documentation yet.

📋 Checklist:

• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "[vNext]" section of the CHANGELOG, linking to this pull request & included my GitHub handle to the release contributors list.

---

This text was originally taken from the template of the Cucumber project, then edited by hand. You can modify the template here.

[gasparnagy]

We need to rework this according to the final solution in reqnroll/Reqnroll#876 🙁

[clrudolphi]

Parking this; keeping it around temporarily for reference.
Going to break this into two parts: first one will do the generation (respecting the configured setting in reqnroll.json).
A second PR will provide a UI (if we ever decide such is needed).

[304NotModified]

@clrudolphi I converted this to draft if that's OK for you :)

[clrudolphi]

@clrudolphi I converted this to draft if that's OK for you :)

@gasparnagy Now that the extension has the capability to generate async bindings, do you want to now reconsider whether to include a triggering mechanism in the UI?

[gasparnagy]

@clrudolphi I converted this to draft if that's OK for you :)

@gasparnagy Now that the extension has the capability to generate async bindings, do you want to now reconsider whether to include a triggering mechanism in the UI?

It's up to us. Having the config setting solves the immediate need. If someone consistently wants to generate async step definitions they can do now.

The real question is how important it is to override the configured style for a concrete case (e.g. you generally want sync step defs, but in one case you want async but you don't like to type the words async Task to the provided snippet). I was happily living without this feature, but I am not against it.

But we should keep in mind that UI changes have to be very carefully done to avoid breaking existing UI. The UI integration to VS (especially styling) is quite magical. Also all UI change have to be tested both in light and in dark themes.

[clrudolphi]

I tend to agree that the UI is not critical. My only regret is that requiring the use of the config file setting is not very intuitive, obvious, or discoverable.

Perhaps in a future version of the extension we provide a settings UI.

[gasparnagy]

I tend to agree that the UI is not critical. My only regret is that requiring the use of the config file setting is not very intuitive, obvious, or discoverable.

Perhaps in a future version of the extension we provide a settings UI.

Yes. That is always in my wish list, but requires a lot of work.

Maybe we can just add a link to the define steps screen that points to the relevant part of the documentation where the configuration setting is explained...

[304NotModified]

The real question is how important it is to override the configured style for a concrete case

Just to add my 2 cents. I think I need for 50% of the cases async.
So it could be a checkbox, but most of the time I'm only sure it needs to be sync or async when implementing 🤣
So I will set the step generations to async, as it's easier to change from async to void.
Conclusing, I dont think we really need the GUI.