Home » Ruby Tutorial Box » TDD & BDD Best Practices with RSpec in Creating Web Service

TDD & BDD Best Practices with RSpec in Creating Web Service

December 23, 2013Colin Dao Ruby Tutorial Box, TechNote No Comment

: TDD Process

Hi everyone, I think that many of you have heard about TDD, BDD. Although you may appreciate this process of software development, you may not have opportunity to work with the process. Today, I want to give you an overview of TDD, and a tool called RSpec for behavior testing in Ruby. Let’s start!

I. Overview

1. TDD

TDD stands for ‘Test-driven development’, a software development process in which we repeat the cycle: Write test first → Code → Refactoring through the life time of project.

2. BDD

TDD stands for ‘Behavior-driven development’ which bases on the core concept of TDD. You write unit tests, acceptance tests, integration tests, etc to check how your application behaves with requirements. However, you must do the same process as TDD. Thus, there’s no clearly difference between TDD an BDD. Writing correct tests in TDD means you are following the BDD. Reversely, doing right BDD means you are doing TDD.

You can find so many results of the two concepts on Internet, in fact, they are the same. It is an efficient process of developing a software, to have a clearly understanding of requirements, good designs, and minimal bugs. Write tests first, then code, then refactoring.

3. RSPEC

Spec is a testing tool for Ruby programming language. RSpec is created under purpose of creating products in BDD process.

RSpec provides:

Rich terminal commands

Automation testing
Textual descriptions which is almost the same with how people think

4. Benefits

Understand more clearly about requirements

Help developers improve code design

Focus on function, output expectations, then validations

Reduce significantly bugs

Ensure functions are connected together in the right way (by integration test)

Make source code more maintainable, more adaptable with changes, more flexible.

Create more freedom for developers to improve source code, change requirements, merge with other features …

II. Practical RSpec in creating a web service

1. Describe method: short and meaningful

Ex1:

describe 'Users#index' do
  describe 'invalid cases' do
    describe 'data' do
      it 'user id' do
        expect sth.to eql sth
      end       
    end 
  end
end

describe 'Users#index' do

describe 'invalid cases' do

describe 'data' do

it 'user id' do

expect sth.to eql sth

end

Ex2:

describe 'admin?'

1	describe 'admin?'

2. Single expectation test

describe ‘valid’ do
  before do
    …
  end
  it {expect response.to be_ok}
  it ‘response format’ do
    … check response
  end
end

describe ‘valid’ do

before do

…

end

it {expect response.to be_ok}

it ‘response format’ do

… check response

end

3. Check response format

describe ‘valid’ do
     before do
           …
          @response = JSON.parse(response.body)
     end
     it ‘response format’ do
         arr_res_fields.each do |key|
             @response.should be_has_key(key)
         end
    end
end

describe ‘valid’ do

before do

…

@response = JSON.parse(response.body)

end

it ‘response format’ do

arr_res_fields.each do |key|

@response.should be_has_key(key)

end

4. Check data

describe ‘valid’ do
     before do
         …
         @response = JSON.parse(response.body)
      end
     it ‘check returned data’ do
          expect @response[status].to eql(1)
          expect @response[message].to eql(‘ok’)
    end
end

describe ‘valid’ do

before do

…

@response = JSON.parse(response.body)

end

it ‘check returned data’ do

expect @response[status].to eql(1)

expect @response[message].to eql(‘ok’)

end

5. Validate params

 describe ‘invalid’ do
     it ‘category’ do
         [nil, 'a', 4].each do |value|
             get ‘products’, {category: value}, HEADER
             expect (response.status).to eql(:bad_request)
         end
      end
end

describe ‘invalid’ do

it ‘category’ do

[nil, 'a', 4].each do |value|

get ‘products’, {category: value}, HEADER

expect (response.status).to eql(:bad_request)

end

6. Use let & subject

let(:account) { Account.create(name: ‘Colin’)}
subject {account}
it {should respond_to(:name)}

let(:account) { Account.create(name: ‘Colin’)}

subject {account}

it {should respond_to(:name)}

7. Create data when needed

describe ‘CRUD’ do
  let(:user) {User.create(email: ‘colin@test.com‘)}
  describe ‘create’ do
    before do
      post ‘users’, {email: ‘colin@test.com‘}, HEADER
      @response = JSON.parse(response.body)
    end
    it {expect(response.status).to eql(:bad_request)}
    it {expect(@response)['message']).to eql(‘email used’)}
  end
end

describe ‘CRUD’ do
  let(:user) {User.create(email: ‘colin@test.com‘)}
  let(:admin) {Administrator.create(email: ‘admin@test.com’)}
  describe ‘Delete’ do
    before do
      params = {auth_token: admin.authentication_token}
      delete ‘users/#{user.id}’, params, HEADER
      @response = JSON.parse(response.body)
    end
    it {expect(response.status).to eql(:no_content)}
  end
end

describe ‘CRUD’ do

let(:user) {User.create(email: ‘colin@test.com‘)}

describe ‘create’ do

before do

post ‘users’, {email: ‘colin@test.com‘}, HEADER

@response = JSON.parse(response.body)

end

it {expect(response.status).to eql(:bad_request)}

it {expect(@response)['message']).to eql(‘email used’)}

end

describe ‘CRUD’ do

let(:user) {User.create(email: ‘colin@test.com‘)}

let(:admin) {Administrator.create(email: ‘admin@test.com’)}

describe ‘Delete’ do

before do

params = {auth_token: admin.authentication_token}

delete ‘users/#{user.id}’, params, HEADER

@response = JSON.parse(response.body)

end

it {expect(response.status).to eql(:no_content)}

end

8. DRY: shared examples

shared_example for ‘listing users’ do |response|
  it ‘response format’ do
    ['status','message', 'data'].each do |key|
      expect response.to be_has_key(key)
    end
  end
  it ‘data format’ do
    ['account_id', 'name', 'avatar_thumb'].each do |key|
      expect response['data'].to be_has_key(key)
    end
  end
  it {expect response.to be_ok}
  it {expect response['status'].to eql(1)}
  it {expect response['message'].to eql(0)}
end

describe ‘friends#index list’ do
  before do
    get ‘users/user_id/friends
  end
  it_behaves_like “listing users”, response
end

describe ‘followers#index’ do
  before do
    get ‘users/user_id/followers’
  end
  it_behaves_like “listing users”, response
  it ‘other custom validations’
end

shared_example for ‘listing users’ do |response|

it ‘response format’ do

['status','message', 'data'].each do |key|

expect response.to be_has_key(key)

end

it ‘data format’ do

['account_id', 'name', 'avatar_thumb'].each do |key|

expect response['data'].to be_has_key(key)

end

it {expect response.to be_ok}

it {expect response['status'].to eql(1)}

it {expect response['message'].to eql(0)}

end

describe ‘friends#index list’ do

before do

get ‘users/user_id/friends

end

it_behaves_like “listing users”, response

end

describe ‘followers#index’ do

before do

get ‘users/user_id/followers’

end

it_behaves_like “listing users”, response

it ‘other custom validations’

end

9. Use FactoryGirl

# factories/user.rb
FactoryGirl.define do
  factory :user do
    first_name “John”
    last_name “Doe”
    admin false
  end

  factory :admin, class: User do
    first_name “Admin”
    last_name “User”
    admin true
  end
end

# Spec
let(:user) {FactoryGirl.create(:user)}
let(:admin) {FactoryGirl.create(:admin)}

# factories/user.rb

FactoryGirl.define do

factory :user do

first_name “John”

last_name “Doe”

admin false

end

factory :admin, class: User do

first_name “Admin”

last_name “User”

admin true

end

# Spec

let(:user) {FactoryGirl.create(:user)}

let(:admin) {FactoryGirl.create(:admin)}

10. Integration Test

describe ‘users#update’ do
  before do
    get ‘users/index’, {page: 1} # cache users
    put ‘users/user_id’, params = {…} # success
  end

  describe ‘check update success’ # pending spec
  describe ‘index user’ do
    before do
      get ‘users/index’, {page: 1}
    end
    it ‘should reset cache after updating user’#pending
  end
end

describe ‘users#update’ do

before do

get ‘users/index’, {page: 1} # cache users

put ‘users/user_id’, params = {…} # success

end

describe ‘check update success’ # pending spec

describe ‘index user’ do

before do

get ‘users/index’, {page: 1}

end

it ‘should reset cache after updating user’#pending

end

11. Code Coverage (Ex: simplecov for Ruby application)

Code coverage with simple-cov

Tagged width:BDD, RSpec, TDD

SEPTENI TECHNOLOGY Developer's Blog

TDD & BDD Best Practices with RSpec in Creating Web Service

Categories

Archives

FIND US ON FACEBOOK

SEPTENI TECHNOLOGY Developer's Blog

TDD & BDD Best Practices with RSpec in Creating Web Service

Related posts

Categories

Featured posts

Archives

FIND US ON FACEBOOK