

The Make-Believe Analyst and the Six Costs of Testing With Cucumber - jackkinsella
http://www.jackkinsella.ie/2011/09/26/why-bother-with-cucumber-testing.html

======
btaitelb
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.

~~~
jackkinsella
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...](https://github.com/cucumber/cucumber-
rails/issues/174#issuecomment-2212386)

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.

~~~
btaitelb
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"?

------
oreoshake
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)"

