I don't think the example story in this post is good for several reasons:
1. it was written by developers instead of the product owner -- good stories are all about business value
2. it seems that it was thrown over the wall instead of communicated -- the whole idea of user stories is about communication
3. it specifies the _how_ (adding subpages) rather than the business goal (you could argue that it's about organizing the information across themes on various pages, but this is a fairly abstract goal, and it's not clear that the goal is achieved).
So it's my belief that this is more of a straw-man argument, taking a feature that's an integration test rather than a user story, and using this to argue why using cucumber isn't good for this sort of thing.
I agree, don't use cucumber if all you want to do is write integration tests. But if you're trying to communicate good user stories and acceptance tests, and the communication is there, then I've seen this work brilliantly first-hand, saving costs, and providing business value quickly.
I'm the author. I choose the example story because it featured in a famous blog post called "You're Cuking It Wrong", a post ubiquitously referenced throughout the Rails community as an example of how to use Cucumber correctly. My point is that the common conception of how to use Cucumber is misguided. The creators of Cucumber realize this and have mirrored by thoughts over on Github today. https://github.com/cucumber/cucumber-rails/issues/174#issuec...
I don't think there is anything wrong with Cucumber per se, and I'm sure it can provide business value when used correctly in the appropriate circumstances. If my post suggested otherwise tell me how and I will make appropriate modifications.
I guess most of my beef is with "You're Cuking It Wrong" for giving such a poor example, which I think only furthers your point that we tend to develop bad code with cucumber and then tell clients that this is how they should be communicating.
I've seen this with developers who are trying to practice TDD with cucumber features, and so they _engineer_ the feature as well as the steps, often in a DRY effort, and we end up with this creature that's neither a good scenario nor good code.
I use cucumber because I feel a good feature conveys enough of the business value (the why behind the feature) to guide development decisions, while leaving development/ui/ux teams to autonomously determine the _how_, and at the same time conveying objective acceptance tests. This communication gap between requirements and specification has always plagued engineering, so I find the user story a nice compromise for web apps. This compromise is only effective, however, when the communication channel is there, and as you point out in your post, it often isn't.
I'm curious what your thoughts are in terms of bridging this gap so that developers build what the product owner has in mind. It's one thing when everyone involved is a great communicator, but how do you play the game when, for example, you have a client who says something like, "As an admin, I want a button in the upper left corner, so I can click it and be brought to a list of posts"?
This is one of the funniest articles I have ever read. Anyone who believes in this article clearly lives in an alternate reality. Every single point the author makes is either invalid, a personal preference, or just silly. Besides, anyone running cukes runs them in parallel with auto generated "second testing environment(s)"
So it's my belief that this is more of a straw-man argument, taking a feature that's an integration test rather than a user story, and using this to argue why using cucumber isn't good for this sort of thing.
I agree, don't use cucumber if all you want to do is write integration tests. But if you're trying to communicate good user stories and acceptance tests, and the communication is there, then I've seen this work brilliantly first-hand, saving costs, and providing business value quickly.