Introduction to unit testing

INTRODUCTION TO UNIT TESTING
WITH RSPEC
by Artem Szubowicz

WHY TESTING?
JUNIOR DEVELOPER'S GUIDE
1. write code
2. write more code
3. write event more code!
4. run and check
5. if it crashes - debug & goto 3
6. goto 1

WHY TESTING?
Writing unit tests does not give you profit
immediately.
Instead, it does give you great profit in the
future.

WHY TESTING?
1. descriptive tests substitude documentation
2. finding bugs/errors is much faster
3. refactoring is safe
4. stubbing units still allows you to write logic for them
5. continuous integration

WHY TESTING?
JUNIOR DEVELOPER'S GUIDE
(for those who tried testing)
1. write code
2. write more code
3. cover 100% of code with tests!
4. run
5. if it crashes - debug
6. goto 1

WHY TESTING?
WHAT'S WRONG HERE?
do we need to test everything?

WHAT IS UNIT TESTING?
testing modules, classes and methods, written by us

WHY TESTING?
MIDDLE DEVELOPER'S GUIDE
1. write code
2. run
3. if it crashes - debug & fix it
4. cover it with tests
5. goto 1

A GOOD UNIT TEST IS
CONSISTENT
Same test, run with same code multiple times,
should always give same results.

A GOOD UNIT TEST IS
INDEPENDENT
Test should not change any other objects,
except of those, created in the test itself.

A GOOD UNIT TEST IS
DESCRIPTIVE
generated with --format documentationoption
emailValidator
isValid
for valid e-mail address
resolves with valid=true
for email address that is not valid
resolves with valid=false
resolves with correct reason
for error result
resolves with valid=false
resolves with correct reason
for service down
calls error with error code
isUnique
for non existing email
resolves with false
for existing email
resolves with true

RSPEC
RSpec is a framework for unit-testing in Ruby

RSPEC: CODE EXAMPLE
RSpec.describe OrderBuilder, type: :model do
let(:user) { create :user }
let(:dish) { create :dish }
let(:date) { random_day }
subject(:order_builder) { OrderBuilder.new(user, Date.parse(date)) }
describe '#initialize' do
context 'with date in the past' do
let(:date) { random_day_in_past }
it { expect { subject }.to raise_error(ArgumentError, 'Cannot place order i
end
context 'with date in future' do
let(:date) { 'Sunday' }

RSPEC: DIRECTORY STRUCTURE
RSpec tests (called "specs") are usually placed
in the spec/directory with the same
structure, as app/directory structure.

spec
├── controllers
│   ├── orders_controller_spec.rb
│   ├── restaurants_controller_spec.rb
│   ├── user
│   │   └── orders_controller_spec.rb
│   └── users_controller_spec.rb
├── factories
│   ├── orders.rb
│   ├── restaurants.rb
│   └── users.rb
├── models
│   ├── ability_spec.rb
│   ├── order_spec.rb
│   ├── restaurant_spec.rb
│   └── user_spec.rb
├── rails_helper.rb
├── spec_helper.rb
└── support
├── controller_helpers.rb
├── database_cleaner.rb
├── factory_girl.rb
└── request_helpers.rb
factoriesand supportdirectories are specific to RSpec

RSpec will look for files, whose names end
with _spec.rband run them.

RSPEC: TEST COMPONENTS
describe
subject
let
context
it
expect
create (FactoryGirl)

RSPEC: TEST COMPONENTS
Each test should start with
RSpec.describe, to allow usage of all
other components.

RSPEC: DESCRIBE
Groups test cases and defines the type of
subject being tested.
RSpec.describe OrdersController do
describe '#index' do
# ...
end
end
RSpec.describe OrderBuilder, type: :model do
describe '#initialize' do
# ...
end
end
adding a type for subject may add extra features

RSPEC: SUBJECT
Sets the subject being tested.
subject(:order_builder) { OrderBuilder.new(user, Date.parse(date)) }
# use `order_builder` variable
subject { -> { order_builder.place_order(order_params) } }
# use `subject` variable

RSPEC: LET
Defines a variable, whose value will be
calculated when being used.
let(:dish) { create :dish }
# `random_day` method will be called when using `date` variable only
let(:date) { random_day }
# use `user`, `dish` and `date` variables

RSPEC: LET!
Defines a variable with a value immediately.
# `create :user` will be called right now
let!(:user) { create :user }
# use `user` variable

RSPEC: CONTEXT
Groups tests by the environment, test subject
is being used in. Used for the same subject, but
with different input/dependant values.
context 'with date in the past' do
let(:date) { random_day_in_past }
# here the `date` will equal to `random_day_in_past` call result
end
context 'with date in future' do
let(:date) { 'Sunday' }
# and here `date` will equal to `'Sunday'`
end

RSPEC: IT
Specifies test case' body.
it { expect { subject }.to raise_error(ArgumentError, 'Cannot place order in the
# `it` can also have a description
it "does not create order if user has one already" do
user.orders << create(:order, order_date: date)
expect(order_builder.order).to eq(user.orders.first)
end

RSPEC: EXPECT
Specifies test assertion.
expect { subject }.to raise_error(ArgumentError, 'Cannot place order at the weeke
expect { subject.method }.to change(Order.count).by(3)
# when used with `subject` method call:
# subject { order.dishes.count }
is_expected.not_to eq(0)

MOCKING OBJECTS
Stub any object, which potentially changes
externals outside the test, with a mock.

FACTORYGIRL
Allows to create mock objects. But requires
describing them in
spec/factories/FACTORY_NAME.rb

FACTORYGIRL: FACTORY
FactoryGirl.define do
factory :dish do |f|
f.name { Faker::Team.creature }
f.price { Random::rand(0 .. 100) }
f.description 'tasty dish'
f.kind :main_course
association :restaurant
end
end

FACTORYGIRL: CREATE
# uses factory named `dish`
let(:order) { create :dish }

BEST PRACTICES
GIVEN-WHEN-THENSTRUCTURE
# Given:
user.orders << create(:order, order_date: date)
# When:
order_builder.place_order!
# Then:
expect(Order.today.count).to eq(2)

BEST PRACTICES
GIVEN-WHEN-THENSTRUCTURE
# Given:
let(:orders) { [ order1, order2 ] }
# When + Then:
expect(user.place(orders)).to change(Order.count).by(2)

BEST PRACTICES
INFORMATIVE MESSAGES
describe OrderBuilder do
describe '#place_order!' do
subject { -> { order_builder.place_order! } }
context 'with no orders' do
it 'places nothing' do
expect { subject }.not_to change(Order.today.coun
end
end
context 'with one order' do
let(:orders) { [ create :order ] }
it 'places one order' do
expect { subject }.to change(Order.today.count).b
end
end

BEST PRACTICES
ONE ASSERTION PER `IT`

BEST PRACTICES
NO CONDITIONALS
All the situations must be checked by test
cases.
describe OrderBuilder do
describe '#place_order!' do
subject { -> { order_builder.place_order! } }
context 'with no orders' do
it 'places nothing' do
expect { subject }.not_to change(Order.today.coun
end
end
context 'with one order' do
let(:orders) { [ create :order ] }
it 'places one order' do
expect { subject }.to change(Order.today.count).b
end
end

BEST PRACTICES
NO LOOPS
Replace them with (multiple) tests.
it 'sets "delivered" status for all orders' do
expect(user.orders.today).to all(eq(Order.DELIVERED))
end
it 'does not set "delivered" status for any order' do
expect(user.orders.today).not_to all(eq(Order.DELIVERED))
end

BEST PRACTICES
NO EXCEPTION CATCHING
Test should either expect an exception or no
exception to be thrown.
it 'throws ArgumentException' do
expect { order_builder.place_order! }.to raise_exception(ArgumentError
end
it 'does not throw any exception' do
expect { order_builder.place_order! }.not_to raise_exception
end

BEST PRACTICES
If you face any of these in your tests:
conditionals
loops
exception handling
that means your tests need refactoring

BEST PRACTICES
SENIOR DEVELOPER'S GUIDE
(Test Driven Development)
1. write marvelous tests
2. write code
3. run tests
4. if they fail - fix the code
5. goto 1

Introduction to unit testing

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Introduction to unit testing (20)

Recently uploaded (20)

Introduction to unit testing