RSpec Request Specs vs Cucumber
Cucumber has major mind-share these days. Rails 3 in Action and The RSpec Book illustrate how behavior-driven development can be done alternating between integration/acceptance tests and unit tests via Cucumber and Rspec.
Not everyone is such a fan of Cucumber, though. Ryan Bates favors using RSpec request specs instead, and DHH thinks that Cucumber and even RSpec are spurious.
After struggling with Cucumber for a while, we agree with the latter view. The main problem with Cucumber is that its attempt to provide a near-natural language DSL (Gherkin) for integration testing is too clever by half. Gherkin is thoroughly brittle in that can only parse statements defined in step definitions, which in turn make Ruby calls using Capybara (or Webrat). Any breaking test leaves you scratching your head wondering whether it is due to a problem with the Gherkin, the step definition, or the underlying code.
In contrast, simply using RSpec’s request specs lets you skip the two levels of indirection (the Gherkin layer and the step definitions) and just write your tests. Request specs exercise the full stack just as Cucumber does — but without the obscurity.
That said, many developers find that Cucumber is helpful in that clients can read — and perhaps even write — the Gherkin code, which makes the step useful for acceptance testing. In our situation, we don’t interact with clients in this fashion, nor have we ever encountered any that would want to engage at that level of complexity. However, for developers that do, Cucumber may be just the ticket.
The main limitation about RSpec request specs is that they aren’t all that well documented; even The RSpec Book gives them only passing mention and defers to Cucumber. One of the best introductions is Ryan Bates’ Request Specs and Capybara railscast and his follow-up How I Test railscast. And even more useful, check out Ryan’s source code for the Railscasts site itself to see how he writes request specs.