Testing in Rails

Abhishek Yadav

@h6165

Testing models

Testing models

• Sometimes call unit tests. But model tests are not always unit tests

Testing models: no Db

# Within Post model

def summary
  title + "-" + body[0..20]
end

## post_spec.rb

it "should be *Fixing Rails-This should be easy*" do

  post = Post.new(title: 'Fixing Rails', body: 'This should be easy')
  expect(post.summary).to eq('Fixing Rails-This should be easy')
end

Testing models: with Db

# Within Post model

def self.create_sample
  create(title: 'Sample', body: '')
end

## post_spec.rb

it "should create a post with title of sample" do

  p1 = Post.find_by_title('Sample')
  Post.create_sample
  p2 = Post.find_by_title('Sample')

  expect(p1).to be_nil
  expect(p2.title).to eq('Sample')
end

## Other ways

Testing models - with associations

# Within Post model

 def self.having_comments
   Post.where(id: Post.joins(:comments).select('posts.id'))
 end

## post_spec.rb

it "should give posts having comments" do

  p1 = Post.create(title: 'p1', body: 'p1-body')
  p2 = Post.create(title: 'p2', body: 'p2-body')

  3.times{ p1.comments.create(body: '+1', author_name: "author-#{rand}") }

  ps = Post.having_comments
  expect(ps).to include(p1)
  expect(ps).to_not include(p2)
end

Testing model - with associations

## post.rb

def self.posts_about_rails
  Post.where("title LIKE %rails%")
end


## post_spec.rb

it "it shows posts with 'rails' in title" do

  p1 = Post.create(title: 'Rails refactoring', body: 'sample-body')
  p2 = Post.create(title: 'TDD in Ruby', body: 'sample-body')
  p3 = Post.create(title: 'Patterns in Rails', body: 'sample-body')

  ps = Post.posts_about_rails
  expect(ps).to include(p1, p2)
end

2. Data creation with Factories

Simplify data creation with Factories

• Factories are one way to create data for tests 

• Data creation can become difficult when there are validations or there are too many fields

• Gems: factory_girl, machinist, fabrication

• Rails default is Fixtures 

• Factories are: declared once, use everywhere

# Simple example


factory :post do
  title 'sample-title'
  body 'This is the body of the sample post'
end



## Usage: post_spec.rb

it "it shows posts with 'rails' in title" do

  p1 = create(:post, title: 'Rails refactoring')
  p2 = create(:post, title: 'TDD in Ruby')
  p3 = create(:post, title: 'Patterns in Rails architecture')

  expect(Post.posts_about_rails).to include(p1, p2)
end

Simplify data creation with Factories

## Slightly more evolved: creating associated data

factory :post_with_comments, class: Post do
  title 'sample-title'
  body 'This is the body of the sample post'
  after_create do |post, evaluator|
    3.times do
      post.comments.create(body: 'sample comment', author_name: 'Abhi')
    end
  end
end

## Usage: post_spec.rb

it "should give posts having comments" do

  p1 = create(:post_with_comments)
  p2 = create(:post)

  ps = Post.having_comments
  expect(ps).to include(p1)
  expect(ps).to_not include(p2)
end

Simplify data creation with Factories

# Creating associated data using another factory
## spec/factories/comments.rb

factory :comment do
  body: 'sample-comment'
  author_name: 'sample-author'
end

## spec/factories/posts.rb

factory :post_with_comments, class: Post do
  title 'sample-title'
  body 'This is the body of the sample post'
  after_create do |post, evaluator|
    3.times do
      FactoryGirl.create(:comment, post_id: post.id)
    end
  end
end

Simplify data creation with Factories

# Kitchen sink: for User model

factory :registered_user, class: User do

 name 'example-name'
 date_of_birth 35.years.ago
 gender 'Male'

 # unique email using sequence
 sequence(:email) { |n| "registered#{n}@example.com" }

 # using variables
 password 'example-password'
 password_confirmation { |u| u.password }

 # Creating belongs_to association
 company { create(:company) }

 # Callbacks
 after(:create) do |user, e|
   user.add_role(:general_user)
 end
end

Simplify data creation with Factories

3. Mocks and stubs

Mocks an stubs: the need

• Simulating difficult behaviour​
  • A complex query involving several models
  • A slow step (like external API calls)
  • A cost ($) sensitive step (API call involving a paid service )

• Simplifying dependent objects

  • Our code could be dependant on objects of other types (class/model).

  • While writing tests, we have to make sure these objects are created and configured correct to have the desired outcome

     

# The syntax: allow


allow(user).to receive(:send_registration_email).and_return(true)


allow(address).to receive(:geocode) { [13.5, 81.5] }


allow(deep_thought).to \
  receive(
    :answer_to_the_ultimate_question_of_life_the_universe_and_everything
  ).and_return(42)

Mocks and stubs: syntax

# The syntax: double

post_double = double(title: "Im a double")
allow(comment).to receive(:post).and_return(post_double)


allow(comment).to receive(:user){ double(username: "abhi") }

Mocks and stubs: syntax

# The syntax: stub at class level

allow_any_instance_of(Address)
  .to receive(:geocode)
  .and_return([13.5, 81.5])

Mocks and stubs: syntax

# Method under test: (within User model)
def send_email
  UserMailer.registered(self).deliver!
end

def complete_registration
  self.state = 'registered'
  self.save

  send_email
end

# In this test case, we are only checking the value of state
# We can have a separate test for email delivery,
# but in this one, we are not concerned with the email part

it 'should mark the state as registered' do

  allow(user).to receive(:send_email).and_return(true)  # <= here

  user.complete_registration
  expect(user.state).to eq('registered')
end

Mocks and stubs: stubbing email

# Summary of comments, contains the user's name,
# and the first few characters of the comment body
#

def comment_summary
  post.title + "-" +
  self.body[0..10]
end


it "shows post title in comment summary" do
  c = Comment.new(body: 'Hello')

  allow(c).to receive(:post){ double(title: 'abc') }

  expect(c.comment_summary).to eq('Hello-abc')
end

Mocks and stubs: dependent objects

Mocks and stubs: definitions

Note: 

Definitions are not standardised, so this as a general idea at best

def send_email
  UserMailer.registered(self).deliver!
end

def complete_registration
  self.state = 'registered'
  self.save
  send_email
end

# We want to make sure 'send_email' is invoked,
# even if email is not actually sent
# This test fails if we remove the 'send_email' call from above code

it 'should try sending the email' do

  expect(user).to receive(:send_email)
  user.complete_registration
end

Mocks and stubs: mock example

# Complex example: within the User model

## Create Location record, geocode it, and associate it
def update_locations(country, state, city)
  if !country.blank?

  l = Location.where(city: city, state: state, country: country).last
  l = Location.new(city: city, state: state, country: country)

  if l.latitude.nil? || l.longitude.nil?
    lat, lng = Geocoder.coordinates("#{country}, #{state}, #{city}")
    if lat && lng
      l.latitude = lat
      l.longitude = lng
    end
  end

  l.save!

  # Associate the Location with partner
  ul = UserLocation.where(user_id: self.id, location_id: l.id).last
  if ul.nil?
    ul = UserLocation.new(user_id: self.id, location_id: l.id)
    ul.save!
  end
end

Mocks and stubs: use in complex code

## Test case 1
## Location does not exist, Geocoding is possible

it "test-1" do
  user = User.new
  allow(user).to receive(:id).and_return(1)
  allow(Geocoder).to receive(:coordinates).and_return([13, 83])

  user.update_locations('India', 'Tamil Nadu', 'Chennai')

  location = Location.last
  expect([location.latitude, location.longitude]).to eq([13, 83])
end

Mocks and stubs: use in complex code

Here we stub the Geocoder to return fake values we can use.

We also stub the partner#id to avoid saving it (it is used in the last part of the code)

## Test case: 2
## Location exists, Geocoding should not be invoked

it "test-2" do
  user = User.create
  Location.create(country: 'India', state: 'Tamil Nadu', city: 'Chennai')

  expect(Geocoder).to_not receive(:coordinates)
  user.update_locations('India', 'Tamil Nadu', 'Chennai')
end

Mocks and stubs: use in complex code

Here we mock the Geocoder to make sure it is not called.

Mocks and stubs: too much mocking

• Too much mocking is not good because its hard to follow the code. Its hard to differentiate what is tested and what is mocked.
• If creating test-doubles starts taking too much effort, its better to create real objects

Thats it. Thanks

@h6165