(ps: For those not familiar with cucumber, it provides a DSL to describe application behavior in plain-text, which is then translated into runnable tests. http://cukes.info/)
More like a DSL to describe application behaviour in not really plain text from which you then manually copy your assumptions into slightly less plain text DSL shim to actually run the tests.
It's far from wasteful for us. The stories we write are exactly plain text which we have successfully had clients help us write. Unfortunately some programmers don't speak "plain text" and insist on writing code-like stories using "tables" instead which then can make it very, very wasteful.
For us, the mere excercise of writing the stories with customers has been very useful in getting the requirements out of their heads. We can then say "You helped us write these, the app does what you said you wanted it to" and there are less issues with communication.
It's saved us time and money. Here's just an example of how we use it, using EmailSpec.
Given I'm logged in to the central authentication service as "bphogan"
And I am on the home page
Then I should see "Welcome, Brian"
When I select "Administrative Information"
And I follow "Change Address"
Then I should see "Fill in this form to change your address"
When I fill in "Address 1" with "123 Fake Stree"
And I fill in "City" with "Springfield"
And I select "OR" from "States"
And I fill in "12345" for "Postal Code"
And I press "Change Address"
Then I should see "Your address has been updated"
And I should receive an email
When I open the email
Then I should see "We have updated your address"
That alone tells a client so much about what we're doing, and tells the developers what real tasks need to be extracted from the story to make it all pass. Things like "select" and "fill in" are already done for you. There are only two custom tasks in this scenario, and we wrote those once and share them across projects.
It's plain text, it's just not freeform. But that's nitpicking either way. It's human readable, and I took issue with the 'such a waste' comment, because it's proved value for us many times over.
EmailSpec gives me step definitions for dealing with opening emails in a "virtual" email box. Very handy stuff.
I used to feel the same, however having spent significant time on a project with a well-written (and factored) cucumber suite recently has brought me around to their camp. To each their own though, I suppose.
It reminds me of ANT and how it eventually became a (poor) programming language in XML. The idea of writing code in human text never really appealed to me (personally can't stand AppleScript).
That said, I haven't worked extensively with Cucumber and would love to hear opinions to the contrary. Hard to tell if it's a Ruby fad or a genuine improvement in workflow.
http://relishapp.com/rspec
Tests as documentation are really coming around.
Sincerely, A cucumber convert
(ps: For those not familiar with cucumber, it provides a DSL to describe application behavior in plain-text, which is then translated into runnable tests. http://cukes.info/)