And then once you get over the knee-jerk reaction the twitter community been teaching you, you might look at the actual syntax and the way the language conceptualizes stuff, and might actually learn something new and useful :) Or, at least have something constructive to say, even if it's negative or whatever, instead of just wasting space.

You're making an assumption here. I don't read Twitter, I have no idea what reaction that community has and I don't care.

My insight on Cucumber comes entirely from years of experience, through several organizations using or considering using it. Several times I was successful in stopping its planned use.

I thought the negative comments would come through the sarcasm, but point taken that it's not constructive.

I think Cucumber (Gherkin) and any natural-language attempts are rooted in a core delusion that product managers or non-technical people will write these test cases. I've never seen product managers writing or even reading these cases. They are not written at the functional specification or an SRD level, because that level is too high and too imprecise to capture the realities of testing behavior.

The natural language of Gherkin is parsed by a set of rigid regular expressions, which do not support the full richness of the English language, and subtle changes like adding or dropping an article or lightly altering the word order will render those steps unparsable. So it's not natural language, it's a programming language with all the syntactical strictness of one, but highly sugared and natural-looking.

You can write behavioral tests at the same exact level as Gherkin in any reasonably-expressive language, likely whatever language your code is written in. You can choose to have fixtures, and high-level structure and you can banish low-level detail from your test cases. Code can do all that, and MAINTIAN EASY refactorability. Code has natural ways in which it can create new layers of abstraction over repetitive ideas, at whatever level is convenient.

But with Gherkin, you're faced with "now I have to write new steps that call the implementing code of the old steps or figure out if I can call the old steps directly and have them still work in a sequence". It is no longer a matter of using your "Extract Method" or copy-pasting some lines into a method with parameters.

Because Gherkin introduces so much more friction/resistance to refactoring, those feature files are much less likely to be refactored. Thus, the copy/pasting of blocks of steps will continue and the tests will start losing that higher level expressiveness that was the justification for using Cucumber.

Testing behavior is a good idea. Writing your tests at a very high level, where you can understand the whole scenario at a glance, and give it data tables to consume, and follow that Given/Then structure, is all possible with code.