Is Cucumber simply a wrapper around rspec to help organize tests into features?_问答_开发者

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?

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.

I use shoulda, but rspec is fine too.
I write my negative-auth tests (i.e. Access denied is expected) as Rails functional tests.
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.

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.

I'd say you understanding is incorrect.

Unit test and Cucumber steps are completely different and largely unrelated things.

Cucumber Tests are combination integration/user acceptance tests and as such are supposed to be independent from the actual implementation in code. So theoretically you could completely rewrite your app in a different language and your cucumber tests and possibly steps should still be useful assuming you haven't changed your applications behaviour. Unit tests on the other hand are intimately related to the code, testing things like return values of specific method calls, edge cases related to data structures, etc... Change a method and you have to change your unit test.

There are some good screencasts out there that talk about using Cucumber and RSpec to build/test your app from the outside-in. Here are few that should help you get started improving your understanding of how integration tests and unit tests can fit together:

http://blog.josephwilk.net/ruby/outside-in-development-with-cucumber-and-rspec.html

http://rubyconf2008.confreaks.com/rspec-and-cucumber.html

http://confreaks.net/videos/72-mwrc2009-bdd-with-cucumber

My own personal use of Cucumber is a bit heretical in that I often use just cucumber on smaller projects as it replaces the monotony of running and rerunning scripts that are just not important enough to do full unit test driven development on. This is however definitely not the community consensus (at least in public) on how to do things.

Cucumber is not a wrapper around RSpec. RSpec is a tool used to drive you code at a unit (one class at a time) level while cucumber is a tool to define features of your system that are in turn automated.

RSpec specs are typically written one at a time as the codebase evolves. We specify the next small behavior of the class we are currently writing.

Contrast that to Cucumber where we write a set of Scenarios that are nothing more than an example of how the system will be used by an end user. Typically most of the Scenarios are written prior to beginning of development and they serve the purpose of defining what functionality the feature should contain. In an Agile environment a feature is considered functionally complete when all of the Scenarios pass.

In smaller shops the developers write both the Cucumber Features/Scenarios as well as the RSpec specs. In larger shops these activities are divided between developers writing the specs while the product owners and testers write and automate the scenarios.