BDD and Gherkin

Behaviour-driven development is a conversation format before it is a tooling choice. The practice is that a business representative, a developer and a tester agree concrete examples of how a feature should behave before the feature is built, and that those examples become the specification. Gherkin is the plain-text notation those examples are written in — given a starting state, when something happens, then something is observable — and a runner binds each line to code so the examples execute as tests.

The value sits almost entirely in the first half, and this is what most adoptions miss. Teams buy the syntax, skip the conversation, and end up with automation written in an English-like dialect by engineers, for engineers, that no business reader has ever opened. That is strictly worse than an ordinary test suite: the same coverage, plus a parsing layer, plus a step library that has to be maintained, in exchange for a readability benefit nobody is collecting. The honest test of an adoption is whether anybody outside the engineering team has read a feature file this quarter.

Signs it is being used well, or badly

• Scenarios describe behaviour rather than interaction. "When the customer submits an order over the credit limit" is specification; "when I click the button with id checkout" is a script with extra ceremony.
• Steps are reused across features by meaning, not by wording. A step library where three near-identical phrasings each have their own implementation is already unmaintainable.
• The examples were written before the code. Feature files produced afterwards to satisfy a process requirement are documentation of what was built, which nobody needs in this format.
• Scenario count stays proportionate. The notation is expensive per case, so it belongs on the behaviours that carry business consequence rather than on every permutation.

If no non-engineer reads the feature files, the notation is pure overhead — the practice is the collaboration, and the syntax is only the record of it.