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).<p>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.<p>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.
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)"