In my experience it's a joke. It's a way for devs to write executable document strings for the tests they also write.

Absolutely no business person who is responsible at the level BDD works (the head of marketing for example) ever ever ever writes a working BDD description or frankly bothers reading them.

Maybe just maybe they are useful intermediaries for Business analysts but most of those have been fired.

Fitnese tests have more traction but then this is just exposing your API for user tests

This matches my experience. I used to somewhat blame the business folks for being too lazy and/or pompous to bother with their side of the bargain, but I've come to think it's just generally a solution to the wrong problem. The hard part is correctly translating from what is asked for to what is implemented, and executable requirements don't have anything to say about that step. In cucumber, I can take any arbitrary Given / When / Then statement and implement it in any way, including ways that are completely wrong and (worse) ways that are subtly wrong. The translation code just becomes yet more code that may or may not be correct, and in my experience, it can be a lot of code. When you find yourself wanting to write unit tests for your acceptance test pseudo-english translation layer code, you're deep in a rabbit hole.

i think this (the parent post) is truth: i've had conversations a/b behavior specification where edge cases simply aren't taken into account. so the specification would say, for example

"it does this when anyone clicks a button."

whereas there's often some implicit question, like

"what happens when two people click the button at the same time?"

and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.

In general, BAs should not be writing the stories, but they should be able to read them together with the developers.

I find that it helps, but it doesn't solve the whole problem. The most useful bit is the stories with examples, as those are what are so often missing from specs.

The problem with edge cases is that they are infinite. If there's an edge case that's likely to happen (ideally based on evidence of past behaviour), then it can either be in the spec or just in functional tests.

I like to think that BDD is like writing the documentation first. Would you put the edge case in the documentation? If not, it probably isn't the BA's responsibility to decide what should happen, and it shouldn't have a Gherkin-style story.

But it's not a silver bullet. It's a tool that helps solve some problems on some projects in some teams. Usually, it helps in cases where the domain experts are not very technical and where the domain problem is a fairly simple set of business rules.

This is my experience as well. Cucumber and the like sound like a way to get 'the business' involved more, but in practice the cucumber files just become yet another thing that the developers or testers have to write. At which point you are better off with more traditional testing methods.

> the cucumber files just become yet another thing that the developers or testers have to write

yep, if (and it's sounding more and more like "when," even outside of my anecdotal experience) that decision is made, there's not much point in using cucumber or similar.

i was kind of hoping someone would say, "yea, our product manager writes domain-specific specification files, and the workflow is so much easier!" ... but no, i'll just continue being mildly cynical a/b the role of developers in industry.

I'm more of a PHP developer, so I use Behat instead of Cucumber. However:

1. The value of BDD is that you have some stories with examples written in the language of end users. You can use a tool like Behat or Cucumber that parses those stories and runs them as automated tests, but it's not fundamental, and you shouldn't avoid using BDD just because the automation aspect is too difficult.

2. Avoid using Behat to interact with the browser, make HTTP calls or run command line scripts. Otherwise your features become too tightly coupled with your views. Use Behat to test your services and domain entities directly, and not to test the framework, because testing the whole application (including the framework, if you're using one) is slow and wasteful. If you want to automate the browser, there are better/faster options than Cucumber and Behat.

3. BDD features are not the same as functional tests. Your features should focus on the typical use cases and read like end-user documentation, while your functional tests should include edge cases and should be optimised for developers.

Negative experience here: someone tried to use it as a silver bullet and it made underlying problems worse.

Our "tests" are all written by "tell me what to click" QA, and the Behat source is literally commented-out because they cannot be run by programs, only the QA who made them.