webrat: Automated Acceptance Testing with RSpec or Cucumber

Recently, I was looking deeper into how we could add some automated acceptance tests to our Ruby on Rails based website. We’re using RSpec since quite a while now for TDD, but doing some high level acceptance tests was not on our agenda so far.

DRY Cucumber Scenarios

The new cool kid on the block is Cucumber. One of its main features is that you can describe acceptance tests in nearly plain English (or any other language) simplifying discussions with the product managers and other, non-technical stake holders. I’m really impressed by the ease, with which you can describe DRY scenarios like our login feature:

Feature Login
  In order to be able to contribute
  users
  want to login

  Background:
    Given the user "kanban" exists
    And I am logged out
    And I am on the login page

  Scenario: Login a with valid user
    When I fill in "Benutzername" with "auser"
    And I fill in "Passwort" with "secret"
    And I press "Einloggen"
    Then I should see "Meine Seite"
    And I should see "Neuigkeiten auf meiner Seite"

  Scenario Outline: Login with invalid credentials
    When I fill in "Benutzername" with ""
    And I fill in "Passwort" with ""
    And I press "Einloggen"
    Then I should see "Einloggen"
    And I should see "Der Benutzername oder das Passwort stimmt nicht"

    Examples:
      |user_name|password|
      |auser|bla|
      |bla|secret|
      |bla|bla|

Background, Scenario Outline and Example are the keywords enabling DRY descriptions.

Hooking Scenrios to your app using webrat

As I described in my previous post about Acceptance Testing with Cucumber, Cucumber comes with a set of pre-defined steps for webrat. So the steps are usually single line calls to webrat’s API:

When /^I open (.+)$/ do |url|
  visit url
end

Acceptance Testing for a pure technical team

So far, so good. Cucumber works great and has a very descriptive language perfectly suited for talking to non-technical folks. In our team, the situation is such that we hardly have to communicate in such great detail with our CEO – he’s mainly interested in the rough workings of a feature, but not in the details (he has other things to worry about 😉 ). As the product development team only consists of three tech guys, we wondered whether it’s necessary to have the English language abstraction. Wouldn’t it be nicer just to use RSpec with webrat to make it immediately obvious to technical folks, what the test really does (instead of hiding the details in step descriptions?

To be honest, I was not sure whether it was a good idea to go from Cucumber to RSpec. I feared that the tests would get cluttered by syntax and be much longer (and harder to read) than the Cucumber features. But, I gave it a try. And I was surprised. See for yourself – the same feature side by side as RSpec description and Cucumber feature:

Surprisingly enough, re-writing the feature as RSpec description does not bloat it. In fact, for a tech guy, it is easier to read than the feature as you see exactly what is happening right away. Additionally, you’ve got full Editor/IDE support for writing specs.

RSpec vs Cucumber

Cucumber is great. If you talk in detail about features with non-technical folks, it is the way to go. If you do not have to bridge such a gap between tech and non-tech guys, you might be better off using webrat directly from within your specs. It removes one layer of indirection and doesn’t really make things worse to read, if you adapt best practices for structuring your specs from cucumber (like using examples and well named helpers).