From here
-
Plain text have no value if people writing and reading the specs are developers. Code is natural language for developers (specially if that code is Ruby). Having a client who reads the specs is a possible situation and Cucumber is cool there, but in my experience that situation is not the most common one. If in your case there's no value in having your specs in English rather than in Ruby, Cucumber is an additional layer of abstraction in exchange of nothing.
-
There's a myth about clients writing the specs. It sounds like a unicorn to me, but let's take it. Still, I wouldn't want it. Clients are experts in problems, I am expert in solutions. I want the client to describe the problem I have to solve, not to describe the solution.
-
Some people say Cucumber is cool because you write the stories, the client validates them, and then you can start developing. That is not Agile. The only product from software development that can be validated (if at all) is the software itself. I'm not making that, it's on the second line of the Agile manifesto. In order to get feedback from the client, a quick subfunctional but working prototype is muuuuch better than any plain text story, and thanks to tools like ours (Rails, jQuery, and why not the lighter approach of Steak) we can get it in hours.
-
In Cucumber, features and steps maintenance gets harder over time because of that extra layer. That's not bad if it's worth it, but problem is that the main benefit of the stories being in plain text happens in the development phase, not in the manteinance one. You get the benefit at the beginning of the project, and you pay for it for ever (without getting any further benefit).
Fair enough. However, in this case (if the client does not write them) I personally would choose for less layers of abstraction, purely for the sake of less things that could possibly break. (Not saying that Cucumber might not be stable, just theoretically.)
Also, executable specifications are ‘examples’, that still means you need proper documentation. Now if you have these ‘examples’ in Ruby instead of English, at least you have actual API usage examples.