I think a lot of the issue is the misconception that G/W/T feature files can essentially replace specifications/requirements. They can and absolutely should REFLECT the requirements, but they are ill suited to act as the actual specifications themselves.<p>Feature files to me are most effective when they act as a roadmap of the steps one needs to take to effectively test a given set of use cases, NOT a 1-1 carbon copy of the requirements. It should tell a non-programmer what the test is doing without having to dive into the code, while being a scaffold to which a programmer can build their test logic into. If one needs to look at the requirements, one should do just that, read the requirements document, or in the developer's case, read the requirements set forth in the user story. Scenarios are guides to how to navigate what the test is doing, not what the application itself should be doing.<p>Also, I often see programmers attempt to write a BDD test and run into a case that doesn't quite fit flush into G/W/T, then ask the community of how they might go about writing that test. Instead of understanding flexibility, they are met with an abrupt "that's not BDD, you are doing it wrong, if you did it the BDD way everything would work out". That's discouraging, frustrating, and destructive. G/W/T is not gospel, and it doesn't fit all test cases. I see nothing wrong with fudging some tests to not follow Gherkin to-the-letter if it better facilitates a test while still remaining clear what the test is doing in plain English within the feature file's scenario.