Question

I’m getting started with cucumber, and I have written the following step definition, which basically I copied from the rspec test I already had.

Given /^There is a picture on the screen$/ do
  describe PagesController do
    describe "GET 'home'" do
      it "should be successful" do
        get 'home'
        response.should be_success
      end
    end
  end
end

Now I’m also quite new to Rails. But this seems a bit long to me, can’t I make it any shorter?

Answer 1

What you’re doing there is a big antipattern when writing tests with Cucumber. You haven’t broken down your step far enough—when you look at the test you’ve got, you’re actually going through at least a couple of different steps, one of which isn’t something you want to test. A better test for this would be:

Given I am on the home page
Then I should see a picture

The first step you get for free when you install capybara’s web steps, provided you are using the default path helper in features/support/paths.rb. The second one would look like this:

Then "I should see a picture" do 
  page.should have_selector("img.picture")
end

That step is going to look for an image with a ‘picture’ class on it—my arbitrary definition of what a picture is in the context of your application.

Notice that I’m not checking the response status here. The idea behind cucumber (even moreso than Rspec) is that you test things from the perspective of the client. Arguably your client may be a client API, so perhaps checking the status code is appropriate, but in general with a web app, you’re much more concerned about the UI, and a failing status code will manifest itself in other ways, such as a broken UI. Details like status codes are generally implementation details that shouldn’t be tested from a BDD point of view (though they should be covered in your unit tests.)

FWIW, I also disagree with the assertion that the length of the test is what should determine whether you should be using Rspec or Cucumber. See my blog post on the matter: http://collectiveidea.com/blog/archives/2011/04/15/language-matters/