HN Explorer

26 comments

[ 2.8 ms ] story [ 89.7 ms ] thread
jedediah
What advantage does this give over the built in integration tests?
binspace
Webrat and/or Capybara. Other than that, it is pretty much rspec on top of integration tests.
mguterl
It also gives you the nice syntax "keywords", feature, background, and scenario.
Tichy
Somehow these "real language" extensions for Ruby remind me of the XML craze for Java. To feel right, everything had to be configured in an XML file for Javaists. In the same way, Rubyists apparently feel uneasy if something doesn't read like nice natural language.

I suspect both things are just cleverly masked procrastination....

chc
I agree in most cases, but Cucumber is one of the few times when it really felt beneficial to me. In most cases, I'd rather have straightforward Ruby code like we all understand or a simple YAML config file. But for a declarative spec framework, Cucumber works nicely. Try looking at a Cucumber spec vs. a Steak one and I think you'll see what I mean.

Then again, I am a vegetarian.

jrockway
Why is writing "oh hai, i want my blog to be totally teh awesome. it must have no posts initially, and then should have one post after i add a post with the text OH HAI." better than writing "my $blog = Blog->new; is $blog->post_count, 0; $blog->post("OH HAI"); is $blog->post_count, 1;"?
chc
Since I was speaking about this specific case and not similar DSLs in general, all I can say is that neither of those is valid Ruby with either of these frameworks.
jrockway
I am speaking in general. I don't know Ruby, so I am not going to use that in any code examples.
chc
OK, so given that I said I generally don't think it's beneficial but it is in Cucumber's particular case, why would you ask me how it's beneficial in general?
jamesbritt
" Rubyists apparently feel uneasy if something doesn't read like nice natural language."

Include me out.

With rare exception do I want to spend time trying to get something to read like English; it won't.

And I get tired of guessing which idiomatic "natural" phrasing is to be used for such things in other people's libraries.

Funny you should compare it to XML + Java, because it makes me think, "So you need to write an API. You've decided to make it read like natural English. Now you have two problems."

binspace
+1 I really like rspec because it reads nice and has a nice object model, however, I'm not really compelled to use Cucumber because it seems like a there is overhead involved and I havn't had the case where the project manager needed to read the specs with the developers.
jrockway
Both are YAGNI. Java programmers want the non-programmers to configure their application, but of course, the XML files are actually critical code, so this can't happen. Similarly, Rubyists want "anyone" to write tests, so they figure that a natural language interface will allow that.

The reality is that you are the only person working on your app, and this is all a waste of your time. Just write regular code -- it's more readable and more concise.

eclark
For me the disconnect of translating what I want into natural language is part of the benefit of Cucumber.
shykes
I like Cucumber better. Plain language means you could use it without being a rubyist.

I'd like to see a repository of Cucumber tests for basic HTTP and DOM interaction, with implementations in multiple languages.

igorgue
do you mean webrat steps?
shykes
No. I mean a plain english API to webrat (or an equivalent to webrat). Right now you have to write your own wrapper steps around webrat (unless I've missed something). No wonder people get tempted to just write webrat tests directly.
cschneid
This is similar to Citrusbyte's Stories library (disclaimer, I work for Citrusbyte). http://github.com/citrusbyte/stories

It's a fairly lightweight layer on top of Test::Unit that lets you define nested stories and scenarios, integrating with Webrat (soon Capybara when we get to it).

One differentiating feature of Stories is that you can print out a readable PDF doc with each story, and the specific scenarios that make it up, leaving off the Test::Unit implementation of the scenarios. Because really, clients don't want to read even cucumber's specs. The nasty secret of Cucumber is that it's still programming. You have to be very explicit in what you setup, and what you expect. Even if your explicitness is hidden behind english, it's still there, and many client's just don't think like that. Heck, that's why they hire programmers.

clistctrl
I know this is hacker news... but I was honestly disappointed when the article had nothing to do with Steak.
benatkin
I was disappointed that I couldn't read the README in the git repo without a scrolling past a picture that has nothing to do with BDD.
tarvaina
How many times do we need to go through this cycle?

JBehave: text

RBehave (based on JBehave): code

RSpec Story Runner (based on RBehave): code, later also text

Cucumber (based on RSpec Story Runner): text

Steak (based on Cucumber): code

binspace
Steak is an extension of rspec and sortof inspired by Cucumber. I do remember Obie Fernandez had a blog post about a dsl that looks very similar a few years ago, however I cannot find it.

Maybe I'm going senile.

binspace
I'm happy with Rspec. It accomplishes the same thing with slightly different wording. Actually, I can have Steak in rspec.

  class Spec::ExampleGroup
    class << self
      alias_method :context, :feature
      alias_method :example, :scenario
    end
  end
binspace
Well, duh, Steak is an extension of rspec. Very nice. :-)
jamesbritt
" ... because Cucumber is for vegetarians!"

Is this supposed to be some sort of slight, or a put-down?

Is there something lesser about being a vegetarian?

I'm curious, being, you know, a vegetarian and all.

mguterl
We just started using steak and it is slowly replacing cucumber in our application.

We found the translation between English -> Step Definitions -> Ruby to be too onerous, especially after our stakeholders showed no interest in helping write the scenarios...