Is Cucumber simply a wrapper around rspec to help organize tests into features?

Question

Just want to make sure I understand things.

From what I gather so far, Cucumber is simply a 'wrapper' or a nice way to organize your tests by categorizing things into features and steps, where the actual unit tests are in the steps phase.

It allows to organize your tests into how things will work.

Is that correct?

Answer 1

Sort of.

It is a way to organize tests, but it's more than that. It behaves like the original Rails integration tests were supposed to, but is much easier to use. The big win here being that your session is maintained transparently across the entire Scenario.

Another thing that's going on with Cucumber is that you're (supposed to be) testing from the point-of-view of a browser or client using your code. If you want you can use steps to build objects and set up state, but usually you want your steps to go through the motions required to achieve that state in the first place.

For example you could do this:

Given /I have a user account/ do
  @user = Factory.create(:user)
  # ... more user set up
end

But you should probably do something like this instead:

Given /I have a user account/ do
  visit new_user_url
  fill_in "user_login", :with => "some name"
  fill_in "user_password", :with => "foo"
  # ... whatever else your sign up page needs
end

And of course you can pass in arguments to either of those steps to give your calling code some more fine-grained control over the step's behavior.

What I have generally been doing with my tests is as follows.

1. I use shoulda, but rspec is fine too.
2. I write my negative-auth tests (i.e. Access denied is expected) as Rails functional tests.
3. I write my positive-auth tests (i.e. users doing what they are supposed to be doing) as Cucumber features.

And, of course, I still write Rails unit tests for my models, libraries, helpers, etc.

Answer 2

I like Cucumber because it describes what the behavior is without describing how it is implemented. Cucumber basically decouples the spec (which is also an executable acceptance/regression test) from the implementation. The step definitions are the adapter between the spec and the system under test, which enables the decoupling.

You can also argue that Cucumber gives you a more human-readable spec than RSpec or other Ruby-based syntaxes, which can be understood (even written) by a non-programmer client.