When to switch from cucumber to rspec in the BDD cycle for a login procedure

问题

I'm still trying to understand the combination of cucumber and rspec in the BDD cycle.

I have defined the following scenarios for a very simple login system:

Feature: Log in

In order to get access to the application
As a user
I want to log in

Scenario: User logs in successfully
  Given I exist as a user
  When I go to the login page
  And I fill in "username" with "gabrielhilal"
  And I fill in "password" with "secret"
  And I press "Login"
  Then I should see "Welcome gabrielhilal"
  And I should be redirected to the home page


Scenario: User enters wrong email/password combination
  Given I exist as a user
  When I go to the login page
  And I fill in "username" with "gabrielhilal"
  And I fill in "password" with "wrongpassword"
  And I press "Login"
  Then I should see "Invalid username/password combination."
  And I should see the login page again

Then, I started defining the steps waiting for the right moment to jump into the rspec.

I passed the first step simulating the user with FactoryGirl and defining the step:

Given(/^I exist as a user$/) do
  @user = FactoryGirl.create(:user)
end

I added the route, controller and action for session:

When(/^I go to the login page$/) do
  visit login_path
end

I created the form for log in:

When(/^I fill in "([^"]*)" with "([^"]*)"$/) do |field, value|
  fill_in field, with: value
end
When(/^I press "([^"]*)"$/) do |button|
  click_on(button)
end

I added the flash message to my layout:

When(/^I should see "([^"]*)"$/) do |arg|
  page.should have_content(arg)
end

I added the route and controller (static_pages) for the home page:

When(/^I should be redirected to the home page$/) do
  visit home_path
end

I solved the last step:

When(/^I should see the login page again$/) do
  visit login_path
end

And I got all green... I didn't feel the need of rspec through these scenarios. What am I missing?

I'm trying to understand what I should test with rspec. I don't feel right to test everything again with rspec....

回答1:

My experience with the whole Cucumber/rspec thing is the following: at the beginning when you start with BDD and Cucumber, everything is green and fine like in your example. You can even stick a browser in front of that to do the tests in a real browser. Then you keep adding more and more stuff to your Cucumber test. This is fine and great, because you are testing the whole stack of your webapp which (for me) is a big plus. You are testing what the user sees.

But after your test suite grows big and you start doing stuff like testing for tags in the page that returned, this is when you start to have problems when you refactor code. Also, it Cucumber is slow for large sites.

What I think works best is to use as little Cucumer as possible and as much RSpec as possible. It speeds up tests greatly. So, testing your controllers and models with RSpec and your frontend with Cucumber is in my opinion the right way to go (most of the time, there is not much frontend testing). For areas where all of these things are tightly integrated and you do want to check the whole stack (e.g. like you did with the login), I think that Cucumber is an excellent tool for these situations.

回答2:

Cucumber is for BDD- that's it. It's there to document and test the behavior of your application. As you write code to get each Cucumber step to pass, Rspec is used to test your implementation.

回答3:

One reason you haven't needed to use rspec so far is that your code really is just 'using' functionality (provided by rails from the looks of things) rather than creating functionality. This happens quite alot when you use a framework.

Another reason is that your cucumber scenarios, are working at quite a low level of abstraction. There is lots of detail in them about 'how' you login. Testing at this level overlaps somewhat with the unit test space, so its understandeable that the need for rspec is not yet apparent.

If you wrote your scenarios at a higher level of abstraction, then you might get to see where rspec comes into play.

For logging in I would write something like this for the happy path

Given I am a user
When I login 
Then I should be logged in

And I'd write maybe one or two sad paths, e.g.

Given I am a user
When I login with a bad password
Then I should not be logged in

When you work at this level of abstraction you have far fewer scenarios (takes less time to run), but also much less detail. Now you could cover some of that detail with a unit test. For example if we had a method login_error_message, that you were using in your view, then you might write unit tests to say things like

context 'bad password'
  login_error_message.should == 'bad password'
end

context 'bad login'
  login_error_message.should == 'login not found'
end

Whilst you could write cucumber scenarios to do this, it would be much cheaper (particularly in runtime cost of tests), to use a unit test instead.

Generally you want to use Cucumber to document 'why' you need to be able to login and that you can login, but not to specify how you login. Of course this is very much an art, is highly dependent on your particular context, and very open to different opinions. But if you want to use cucumber effectively you need to get plenty of bang for each scenario you write.

来源：https://stackoverflow.com/questions/18192413/when-to-switch-from-cucumber-to-rspec-in-the-bdd-cycle-for-a-login-procedure