|
|
|
|
|
|
by jackkinsella
5372 days ago
|
|
|
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'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"?