CODEWITHSUNDEEP
ruby-on-railsrspeccapybara
Andy Harvey
Andy Harvey

Reputation: 12653

Rails TDD/BDD - single test for the entire workflow, or multiple mini tests for each feature?

I'm trying to get to grips with TDD/ BDD in Rails. I'm using Rspec and Capybara, and would like to know what is considered the 'correct' approach or best practice.

Here is a contrived example of a sign up process with multiple steps.

User visits registration page, enters email address, accepts TOS, clicks 'register", receives confirmation email, clicks confirmation link, redirects to app, enters passwords, is signed in.

So, is the generally accepted approach to have one test for this entire workflow, or break it apart into mini features.

For example (pseudo code), one test

it "registers, confirms and signins in user" do
  visit registration_url
  fill_in "[email protected]"
  check tos
  click "register"
  last_email should contain "confirm" + confirmation_token
  visit confirmation_url
  fill_in "password"
  click "activate"
  page should have content "signed in!"
end

Or mini features

    it "registers with valid email and tos" do
      visit registration_url
      fill in "[email protected]"
      click "sign up"
      page should have content "email sent"
    end

   it "sends confirmation email with valid email and tos" do
      visit registration_url
      fill in "[email protected]"
      click "sign up"
      last_email should have content "confirm"
    end

it "does not register with invalid email" do
  visit registration_url
  fill in "email###email.com"
  click "sign up"
  page should not have content "email sent"
end

Thanks for guidance on correct or best approaches. Also, what is a good (and up to date) reference for learning more about this. I've found most of the books I've read to give a more 'high level' overview.

Upvotes: 0

Views: 768

Answers (2)

Billy Chan
Billy Chan

Reputation: 24815

Capybara tests are integration tests. They are different beasts. Mini features style is nice in unit testing, but I don't think it could be simply applied in integration tests.

At least two difference in integration tests:

  1. Very often several steps required, so separation to mini assertions often impossible.
  2. They are slow.

But one thing is the same in both unit testing and integration testing:

They play a role as "Documentation"

So, if a integration test involves too much details, and need you to imagine what will happen in page when reading it, it's wrong.

A better style is that you can read it like plain English by hiding the details.

So, I think none of your two styles are nice. For integration tests, I would prefer style like this:

feature "user registering" do
  given_an_user
  when_visting_registration_page
  fill_in_details_and_check_tos
  he_should_see_confirmation_email
  when_visting_confirmation_page
  fill_in_password_and_activate
  he_should_be_signed_in
end

def given_an_user do
  @user = FactoryGirl.create(:user)
end

def when_visting_registration_page
  visit registration_path
end

# ....
# And you can extract some common helper methods into global support if
# they happens often.

Later on, when you browse the tests, you can easily get what it means by reading the main body without checking the helper methods at all.

Upvotes: 2

jamesc
jamesc

Reputation: 12837

It's a matter of personal taste but I prefer a work flow or integration test. Can I recommend that you take a long hard look at the "How I test" railscast which in my opinion is the best cast I have seen. It should at least give you some ideas on how you would like to proceed.

http://railscasts.com/episodes/275-how-i-test

Upvotes: 1

Related Questions