Can we have an @retry attribute?

[alastair-todd]

Someone has made one for Specflow: https://github.com/giggio/xunit-retry

Would be really useful

[ttutisani]

I could think why it is helpful with the code in the feature class, but what's the point of it in Gherkin text? Why would somebody write a specification in Gherkin and care about retry?

[alastair-todd]

Non-atomic 3rd party updates providing false-flag assertions e.g. AWS Cognito - Create

I just want to rerun the whole scenario easily a few times without worrying about trying to code for it

[alastair-todd]

Its a thing

https://docs.cypress.io/guides/guides/test-retries#Custom-Configurations
badeball/cypress-cucumber-preprocessor#697

[ttutisani]

Your answer again explains why it's helpful in code, but it does not explain why it's helpful in Gherkin.

My point was that Gherkin is typically a human-readable specification. A person who writes Gherkin should not be thinking about retries, but instead, they think about functionality, business language, etc. On the other hand, Retry is a technical term, so I don't see much value in supporting a 'retry' attribute in Gherkin. In code, yes, I agree, it may have value.

[alastair-todd]

I hear what you are saying. For us there's no collaboration on the actual code files so business folk would never see it. I'd take practicality over ideology any day :)

That said if you can see a way of rerunning a scenario from the class that would be practical too.

[ttutisani]

Yes, from the code, it will have to be an attribute like this.

I assume it will retry if an error is encountered. Otherwise, just one execution.

[alastair-todd]

On failed assertion rather than runtime error I think no?

[ttutisani]

I would say both cases and valid, so it can be configurable. The attribute could take a base exception type as an argument/parameter and default to AssertException (if I'm typing the name correctly). That would be more robust.