I can tell you why I'm using it, and it's not to enable non-programmers to write tests. (Not anymore, it was at first...) The number one advantage is that usi

I can tell you why I'm using it, and it's not to enable non-programmers to write tests. (Not anymore, it was at first...) The number one advantage is that using Cucumber produces human-readable documentation that is also executable, and through the magic of CI is prevented from becoming stale. I use Cucumber with Rails, and I've actually heard a lot of really good arguments not to use Cucumber. The one thing these all seem to have in common is, they almost universally do NOT completely rebuke TDD at-large. Nobody (competent) is suggesting you should develop by the seat of your pants. They have issues with Gherkin or with Cucumber's implementation specifically, but if your team had success with Cucumber, you would not give it up without planning to have a replacement. You may choose to eschew Gherkin style entirely, and you can certainly accomplish much the same thing using feature testing in modern RSpec and scenarios. This may be easier to refactor for you, but for me a well-organized vocabulary of step definitions makes it so easy to copy a scenario, reorganize the steps, and add some new things to create a new feature, adding almost no new test code. There is also Spinach, which rips out all of Cucumber's regex silliness and declines to enforce a global vocabulary, instead encouraging modular design of scenarios and step definitions (since you might want to say the same thing in two different places and mean two different things.) There is also Turnip, which integrates Gherkin into RSpec and also has many of the same advantages of Spinach, but includes other options (cleaner options) besides the Regex method for building parameterized step definitions. I think this one is my favorite, but my small project still uses Cucumber proper. In the beginning of our project, it was very helpful that my PM was writing out requirements in Cucumber style. It meant that while someone (not a coder, but not an inexperienced PM either) had gone to the trouble to specify requirements with rigor, I could focus on coding, just jump in and start writing features, with a clear target of limited scope, that I could easily follow to avoid straying off into the weeds. Before long my PM got busy with other projects and I took over writing the cucumber stories. Not just me, but the other dev too -- and that was just as well. I often found myself rewriting PM's scenarios anyway, to make them easier to map directly to step definitions, more clear in a context-free sense, or generally less ambiguously specified. These enhancements also made them less human-friendly. Both approaches to writing Cucumber stories definitely have merit. The one thing you need to have is a strong set of test scenarios (however you've implemented them) with good total coverage of the features and the requirements, so that new or changed requirements can be evaluated in the context of the whole program: what features are broken by your change? Two things I have found are also critical when using ATDD: your whole team (at least all of the devs) need to be able to run the tests, and (maybe even more important) you need to have a CI solution in place so that no individual needs to be responsible for running all of the tests after each change when your suite gets too heavy for a pre-commit hook. A regression suite is like a pager: when nobody is on-call then everybody is on-call.