Engineers should refuse to write Gherkin. It's not meant to be for them, it's meant to be for non-engineers to tell engineers (or the systems the engineers make) what they expect will happen. It looks like some flavour of user stories for this reason.

Engineers' responsibility begins at the "code behind" the gherkin layer. Someone needs to enforce this.

Sadly, IMO because gherkin looks like structured language (i.e "code"), and because that's what engineers do, they end up doing it. Either they tricked themselves into thinking they should, or the product team tacitly assumed it was a code thing.

If you're an engineer and you're writing gherkin, you should consider this a "code smell" and consider ditching it. Go for a spec tool one layer closer to your main domain. i.e. just write normal unit & integration tests.

I'm not saying "don't do BDD" or "don't do acceptance tests". You should do that! I'm saying "gherkin should allow product owners/managers to take ownership of reporting on how well the app meets their expectations". But most typically, they don't get it, or they don't want to do it.

I recently worked somewhere where we had dedicated devs-in-test. They wrote most of the e2e tests for the application. They wrote it in Gherkin, which meant that they _also_ wrote the JS/Selenium tests behind them. So they were basically writing two sets of scripts for each test. At some point they explored using a 3rd party cross-device testing platform (lambda test, maybe?) who had their own in-house test script that looked like Gherkin, so it needed a JS/TS code-behind to actually run the tests. So they did it all again!! Such a waste.

This managerial anti-pattern crops up with so many DIY tools; like reporting/dashboard platforms where engineers go through all the work funneling data to a 3rd party tool just for management to open tickets asking the same engineers to build dashboards in the UI. If we knew we were going to get stuck making the reports too, we'd probably choose any option that let's you specify them in some kind of code/markup instead and commit it to version tracking rather than a proprietary platform and their own internal history etc. etc.

Gherkin is useful as a test name. However this should be a string that the test framework uses only for the ui. The executable parts should be normal functions that if needed call subfunctions that take normal parameters.