

Steak 1.0 released or Why Cucumber might not be your best choice - _cavalle
http://groups.google.com/group/steakrb/browse_thread/thread/b90c86d0b7464a56

======
r00k
I switched from Cucumber to Steak for several months and loved it. Getting
away from english specification was a BIG win.

However, two weeks ago, I removed Steak entirely, and am now using pure RSpec
for my integration tests.

If you look at the heart of Steak [1] you'll see it's nothing more than a
couple aliases for existing RSpec methods. 'example' becomes 'scenario', and
'before' becomes 'background'. I'm all for accurate language, but I don't
think switching a couple method names really changes anything important here.

Switching from Steak to pure RSpec was simply a matter of a global search and
replace, and now I've got one less gem to think about.

[1]
[https://github.com/cavalle/steak/blob/master/lib/rspec-2/ste...](https://github.com/cavalle/steak/blob/master/lib/rspec-2/steak.rb)

~~~
cageface
I went one step further and ditched RSpec for straight Test::Unit and
sometimes Shoulda. I don't find the RSpec DSL an improvement over straight
Ruby asserts at all.

------
jws
… where BDD = _Behavior Driven Development_ which, if Wikipedia is to be
believed, is _an agile software development technique that encourages
collaboration between developers, QA and non-technical or business
participants in a software project._

The second definition exceeded my jargon quota for the day:

 _BDD is a second-generation, outside-in, pull-based, multiple-stakeholder,
multiple-scale, high-automation, agile methodology. It describes a cycle of
interactions with well-defined outputs, resulting in the delivery of working,
tested software that matters._

~~~
swombat
That's a load of crap. The best definition I've ever heard for BDD is "TDD
done right". This is certainly what "BDD" started out as. The idea is that the
language of typical testing frameworks doesn't encourage the right types of
tests (i.e. testing behaviour rather than state), and so using a package that
has the right vocabulary, you are more likely to do TDD right.

There is no significant difference between BDD and TDD other than that
terminology, and most leading BDD proponents in the ruby community will refuse
to set it in opposition with TDD. BDD is just a form of TDD, not some separate
discipline. Defining BDD without mentioning its relationship to TDD is stupid.

~~~
purp
BDD means testing that you've delivered what the customer asked for. User
stories expressed as test. This is like the architect's rendering of a
building; it expresses and implies certain desired qualities.

TDD means testing that you've implemented a system which has all the
significant qualities you expected. It intends to prove that the system does
all of the right things and none of the wrong things on the way to delivering
what the customer asked for. This is more like the blueprint of the building,
making all significant details explicit.

You could practice BDD without TDD, though I've yet to see someone choose to.
You can practice TDD without BDD, which I've seen many people do.

~~~
silentbicycle
> BDD means testing that you've delivered what the customer asked for.

No, that's "Acceptance testing", and doing it without TDD is actually quite
common.

~~~
purp
... which is why you frequently hear BDD called "Agile Acceptance Testing"

~~~
swombat
Perhaps by later practitioners of BDD who have no idea what they're talking
about...

RSpec itself is in fact driven by the BDD ideas - adapting the language to
make "doing the right thing" easier, and focusing on testing behaviour rather
than state. RSpec has little or nothing to do with acceptance testing. It is
thoroughly a unit testing tool.

------
mortice
There's an assumption implicit in the announcement (and in a lot of anti-Cukes
stuff I've seen) that the primary benefit in writing your feature
specifications in pseudo-English is that clients get to read/write the
features.

That's not the point, at least as far as I'm concerned. The point is to make
me, as a developer, think like a user and write the specification of a feature
from a user's perspective.

So instead of writing 'page.should have_css(...),' I write "Then I should see
...", and specify the details of that somewhere else. Yes, I could just write
a method 'def i_should_see,' but I'm a developer, and hence lazy and also
comfortable with the detail. That means I'm more than likely _not_ to do that,
but then I've got a spec which doesn't express the feature from the user's
point of view.

I'm prepared to accept that there are developers who are disciplined enough to
write specs with Steak which do express things from the user's point of view,
but I'm certainly not one of them.

------
swombat
For the record, I use Steak instead of Cucumber, and find it far more
convenient than using Cucumber. Effectively, it removes a whole class of
errors/issues that I used to have with Cucumber (errors with parsing the
steps, and issues with getting the steps to do exactly what I want). It's one
less language to learn, too - Steak steps are written in ruby, you don't need
to learn the regexp-driven step-matcher definition syntax of cucumber.

This also means that the tests can be abstracted where appropriate, using the
full power of ruby's syntax. I haven't missed Cucumber since switching to
Steak.

~~~
jdp23
i certainly agree that there are a lot of extra sources for error using
Cucumber, and learning the regexp-style programming and syntax was a pain.

one of the things I like a lot about Cucumber is having precise definition of
stories in a way that I can discuss with actual users. in a Steak world, what
mechanisms get used for that?

~~~
swombat
My cofounder is reasonably technically minded (for a business guy), and yet
I've never seen him glance at more than the headline description of a test.
Steak provides those. The actual steps of the test are just implementation
details. The headline should say what the test does, reasonably precisely.

~~~
bphogan
I routinely write plain-text with my clients and stakeholders - they like
cucumber. I could not show them Steak. When working with end users Cucumber
works really really well for me.

However, the idea of Steak on projects where I'm the stakeholder, or only
developers are working on a team, seems like a nice idea because it is less
maintenance.

------
bryanlarsen
I've never understood the fascination with cucumber. If you've got a customer
in the loop actively working on or reviewing acceptance tests, cucumber is
very nice. If you don't, then cucumber is a big waste of time. For some
reason, cucumber was the ruby/rails "meme of the day" for a while. BDD is
awesome. Webrat is awesome. So if cucumber is your first exposure to those
two, then cucumber seems awesome. Do yourself a favor and try BDD & Webrat
without cucumber.

If steak becomes the meme of the day, at least it isn't actively harmful like
cucumber was.

~~~
YakiSauce
In defense of Cucumber, I've been a rails developer for more than 2 years and
I still find it easier to read English than Ruby. I think the extra layer of
abstraction is well worth the effort when reading over other people's tests.

~~~
bryanlarsen
Have you actually used Webrat? It reads English with extra punctuation. Here's
an example from a test I happen to have open at this exact moment:

    
    
        visit "/special_recipes/new"
        fill_in "special_recipe[name]", :with => "Pie"
        select "Test User", :from => "special_recipe[user_id]"
        click_button "Create Special Recipe"
    

The mind naturally skips the punctuation. It actually reads easier than some
Cucumber tests I've seen.

------
techiferous
"what is exactly the point of making [user stories] executable tests? Because
of their double purpose, features used as tests are worse user stories than
regular user stories and worse acceptance tests than regular acceptance
tests."

Bingo!!!

------
devin
This is an integration testing framework. There's no 'acceptance' about it.

I'll stick to cucumber. English matters in acceptance testing.

~~~
moe
Oh, cucumber speaks english now?

Last time I checked cucumber was the equivalent of inventing an additional,
imaginary stakeholder for every story. A stakeholder who recently immigrated
from a distant country and insists on having each and every spec laboriously
translated to his unusual and very limited dialect of english, before anyone
is allowed to proceed.

I'm all for imaginary friends, but I really think you should refrain from
bringing them to the office if you value your productivity.

------
rbranson
The best part of this whole thing is "NoCukes," an awesome jab at the NoSQL
moniker.

------
growt
When those ruby hipsters release something it sounds like a fucking grocery
shopping list.

[edit:] Yeah vote me down, in your tight jeans and your vintage glasses! ;)

~~~
christkv
They are only vintage because I can't afford new ones

