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).
I think RSpec is awesome at what it does (after all, most of the time I'm still using RSpec's expectations inside Cucumber "Then" steps), but I stick to Cucumber for acceptance testing.
I agree with @jeffkreeftmeijer that Cucumber is most useful when having a client (although in most CLI tools, which live in a wider environment outside the code, can greatly benefit from this kind of executable docs), and I think it is in a sense that software written for clients is meant to model their specific domain. It matters little whether they write user stories or not. The important thing is that both the developer and the client can talk to each other using the same terms. The developer still "reads minds" from their clients and writes down whatever he understands to be the point of what they said, just as in any translation process, but he can always get feedback on that (since the client can actually validate what the developer has understood). That also enables accountability.
For sure it's an additional layer (maybe we should think of it as a safety net), but I think it's a useful one, since it "caches" a particular understanding of the domain problem and enables other developers to work with it at the same level of abstraction.