BDD Without Gherkin

I've been writing acceptance tests in Given-When-Then since 2009 and I've never written a feature file by choice. So when someone asks whether you can do BDD without Gherkin, my answer is that I've never done it any other way. Cucumber has been the default for long enough that the two have merged in people's heads. They shouldn't have. BDD is a way of specifying behaviour. Gherkin is a file format one family of tools uses to do it. What Gherkin is for It does one job. A non-developer can write a scenario in plain text and run it without touching code. If that is what happens on your project, keep Cucumber. A tester or an analyst who opens the repository, writes .feature files and runs them is getting exactly what the format was built for. I've never seen it. What I've seen, on every team, is that the scenario gets written in the ticket. Someone puts acceptance criteria in Jira as Given/When/Then because that's where the work is described and that's the tool they already use. Then a developer types the same words into a feature file and writes step definitions to bind them. The "analysts write the specs" argument turns out to describe a copy step. What it costs Three things to keep in agreement instead of one: the feature file, the step definitions and the code. The IDE can refactor two of them. The third is text, and it's the one people read. Binding by regular expression. Rename a method and the .feature file doesn't follow. Reword a step and the match silently changes. Glue. Step definitions are where the logic actually lives, and they're neither specification nor test. They accumulate. And the report shows you the Gherkin, coloured green or red. Not what the system did. For an acceptance test, what the system did is the whole point: the request that went in, the messages between services, the response that came back. The feature file can't carry any of that. Why it looked like a good idea Cucumber arrived around 2008. Refactoring support in IDEs was patchy and pa