Best practices / Style guide for gauge step syntax

[baumar]

We introduced to use Gauge in our project and found a lot of enthusiasm in the team. Especially the free way to formulate actions is much appreciated. The problem I see raising is that there is no common practice how to formulate the steps.
For instance some people like Gherkin and formulate a Step like "When I do this with param " but then it is not reusable for other use cases and its tests where this action does not happen in the when clause.
Then we suggested in those cases to cut the step description to "I do this with param " so the Gherkin-followers can use it by adding a when or then as a comment in the previous line.
But when we started with role based function we found that we must be able to pass a role into a function so the "I" is rather misleading.

So we start to setup a practice or a style guide how to write these steps to have a consistent style that makes the tests more readable and avoids redundancy in Step descriptions.
Did anybody already do something similar and have information or experience to share?
Thanks for help
Markus

[sriv]

Hi, interesting topic. I'd just like to say that it ultimately comes down to what the team prefers. The tool does not have an opinion on this, and does not enforce a structure. This blog post may also be relevant here: https://gauge.org/2018/11/12/bdd-vs-executable-specifications/

What I personally have realized is that one can make a lot of these questions redundant by choosing a declarative style of writing specs/scenario/steps over an imperative style. A couple of blogs illustrate this:

• https://www.thoughtworks.com/en-in/insights/blog/imperative-vs-declarative-style-writing-twist-scenarios
• https://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off

Hope this helps you in your discussion. If you do come up with a style guide, it'd be awesome if you can share it with the community. At the least, I'd like to think that the idea of a style-guide can be adopted by others as well.