Steak 1.0 released or Why Cucumber might not be your best choice | Hacker News Reader

Steak 1.0 released or Why Cucumber might not be your best choice

groups.google.com

60 points_cavalle28 comments

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

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.

I also use Steak in my everyday job and I think Steak is more an idea than a library. The idea of doing acceptance testing without extra layers such as Cucumber, and some little convenience tools for the job (those aliases you refer, a couple generators and rake tasks, and a common reference for the community on how to do it). I remember @cavalle pointing in Twitter something like "Steak is a gem but it could be a gist".

So using this definition, you're still kind of using Steak =;-) (and actually is what made you do that step).

I think it provides that value, but you can cook it on your own because as you point is not difficult at all.

Totally agreed. We've been using Steak on some projects and find it to be a better alternative when we want to show the client something.

Otherwise, we've just been using Test::Unit or straight RSpec with webrat/capybara.

… 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.

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.

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.

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

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

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.

Liz Keogh's "Translating TDD to BDD" was really helpful to me when I was coming from a test-driven development perspective and just starting to wrap my head around BDD. http://lizkeogh.com/2009/11/06/translating-tdd-to-bdd/

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.

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.

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?

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.

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.

i use Cucumber for behavior definitions, not tests ... and for me it's very useful to be able to discuss this with a non-technical person. "is this how you'd go about accomplishing something? is this how you'd expect the system to behave if you do X?"

[which isn't to downplay the value of tests, those are important too, and I could see Steak potentially adding value on that front]

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.

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.

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.

If you are going to make a blanket offhand statement like:

"actively harmful like cucumber was"

I think you should provide some basis for that. Some examples of how you think cucumber is harmful.

Cucumber is very expensive -- it requires you to maintain a set of rules to map English to ruby. And it causes people to continually fiddle with stuff just so that the English reads write. And it adds an abstraction layer, which are also "expensive".

Great expense, little gain -> actively harmful to projects.

You end up spending lots of "testing time" fiddling with cucumber stuff. It feels productive, but you'd have more, better tests writing straight into webrat

"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!!!

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

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

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.

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

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! ;)

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

Reply on news.ycombinator.com