

Test with Ruby not Cucumber - ryandotsmith
http://afewgoodlines.com/post/1077316188/integration-testing-retrospective-part-i

======
oomkiller
I think you're missing the point of Cucumber (at least as I see it). While
it's great if customers write cucumber scenarios and send them to you (we have
one that does), that's not the main reason for it. Cucumber facilitates
communication between product design and product development/engineering.
Cucumber allows the people with much more domain knowledge than you look at
your specs and tell you if something is awry. I think this is the biggest win
with Cucumber.

One of our clients was dead set on having "functional specs" for every feature
we implemented. With Cucumber, they can read our "functional specs" or write
their own and send them to us. Then, we can use those functional specs for
actual testing, rather than them just gathering dust somewhere on a wiki.

Finally, I do agree that some people overuse Cucumber. Cucumber should really
only be used when adding new features, or when something needs the addition of
communication with stakeholders. Otherwise, you should fall back to unit
testing, or just normal integration testing with RSpec stories or Steak. For
example, I think it's overkill to write a Cucumber test in the case of a bug.
At most, you should have a Steak/RSpec story that reproduces the issue.

------
zach
I think it's great to start (design) high-level tests in human language - in a
chart, in a spreadsheet, in lines or paragraphs. Of course, in Cucumber you
use structured English in a slightly inflexible way.

But the code should be something that you can walk through when you are
running tests. This is what Cucumber is not great at. You want tests that tell
a story, but the code is all in a phrasebook.

After some initial experience with Cucumber, I think I will switch to an old-
school low-tech approach that I've used many times -- design in conversational
English steps, convert those lines to comments, and write code in-between (in
this case, using Steak). The flexibility seems like a much bigger advantage
than the automation Cucumber provides.

------
swombat
You can also use Steak:

[http://jeffkreeftmeijer.com/2010/steak-because-cucumber-
is-f...](http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-for-
vegetarians/)

~~~
cageface
That has got to be one of the least usable blog layouts I've _ever_ seen. It's
all flash over substance, which is rather fitting because you can say the same
thing about a lot of these testing libraries.

Factories are better than fixtures, I'll admit. All this other cruft that's
grown up around Rails testing can be trivially replaced with Test::Unit with
no real loss in readability and great improvements in overall simplicity. If
Test::Unit is good enough to keep Rails itself on track it's certainly good
enough to keep your app under control.

~~~
swombat
Cue religious debate about testing frameworks...

------
ryandotsmith
FYI. I have updated the post with an image describing my customer's feature
development process.

