Stories

@Michael: Code reuse is easy and we do it all the time. You only need to extract the repeated steps to a helper method, so instead of writing the same steps for, say, login, you just do login(@user) and you are done. You reuse code as you would in any Ruby program, by factoring out helper methods.

@Harry: Thanks a lot! I’m glad you like it. Storyteller’s author, foca, is a great friend of mine and we share the philosophy for small and efficient tools.

@Avdi: I think Cucumber gives you a false sense of abstraction, when in reality it’s just saying the same thing twice (in plain text and in code). I consider Stories a Cucumber alternative because it “serves as documentation, automated tests and development-aid”, which is Cucumber’s goal as stated in its website. And it does all that without requiring a huge library like Cucumber, that needs a Treetop parser and formatters because it wants to go from natural language to code, which in my opinion is not wise at all.

@Anonymouse: Both Cucumber and Stories use Webrat for defining the steps, which is what you quoted below the plain English Cucumber features. No matter which library you use, you still need to write fill_in “q”, :with => “rspec” somewhere.

If you are using Cucumber, you will write:

  When I search for "rspec"

…in one file. Then, in another, you have to add this:

  When /I search for "(.*)"/ do |query|

…and finally this:

  fill_in('q', :with => query)

That is, in my opinion, three ways of saying the same thing. With Stories you only need to write that last part, because the text generation is automatic.

I understand your point, though: sometimes you want to hide the implementation details like “q”. We have a solution for that:

  report "When I search for 'Citrusbyte Stories'" do
    fill_in "q", :with => "Citrusbyte Stories"
    click_button "Google Search"
  end

Here is what report does: it silences the normal output and replaces it with the string you pass it. It’s very handy for the case you mentioned, but also when you want to group steps together.

You also said that Cucumber gives you much better naming of things, but you are free to write your own step definitions. To show this, I will cover your point about subroutines. Suppose you are testing Google and you do a lot of different searches. You would want to reuse the fill_in and click_button steps, so you write a search helper:

  def search(str)
    report "When I search for #{str}" do
      fill_in "q", :with => str
      click_button "Google Search"
    end
  end

Now each time you use search you get a better message in your output. And you had to write it only once, while with Cucumber you write it every time.

If you want to add messages for your own helpers or assertions, you can also use the report_for method. We have the following assertion in our test_helper:

  def assert_email_sent_to(recipient)
    assert_equal Array(recipient), ActionMailer::Base.deliveries.last.to
  end

Then, in order to have a nice message, we added this:

  module Stories::Webrat
    report_for :assert_email_sent_to do |email|
      "An e-mail should be sent to #{quote(email)}"
    end
  end

And the result is the same as if we were using any already defined assertion.

These are customizations that you will rarely do, but it’s good to have the ability to change the way you are presenting your user stories. Needless to say, when you need to change some text you do it in only one place.

All in all, the idea behind Stories is to make a more efficient use of your time by letting the program do the work for you.

@Maxim Kulkin: I agree with you and I’m glad you like this tool. Thanks for your comment!

@Michael Heinrich: I haven’t tried it with Watir, and I’m not familiar with it either, but I would say it should work. And if it doesn’t, an adaptation should be very straight forward.

@CRG: I’d say helpers are the way to go for removing duplication. You can define the helpers globaly or for each context, and in any case it let’s you abstract common patterns very quickly.