Unit Testing

A guide to write testable code

Agenda

● Unit Testing
● Dependency Injection
● Mock Object
Type of tests
● End to end, black box testing – tests are hardest to
write and run, tests find bugs that are easiest to fix
(bad markup, wrong css rule)
● Functional, wiring test – easier to write tests, find
easy to medium bugs (cannot connect to db,
because server is misconfigured)
● Unit tests – easiest to write, fix logic bugs and
hard-to-spot design problems (violation of single
responsibility principle, hard-coded function calls)
Unit Testing

“Unit testing is a method by which individual

units of source code are tested to determine if
they are fit for use. A unit is the smallest testable
part of an application.”

– wikipeadia.org
Why and Why not Unit Test

To TEST OR NOT TO TEST

Why Unit Test

● Debugging is a time consuming process

● When new functionality is added, how do we make sure the old one doesn’t
break
● By looking at a Unit Test, you can see the class in action, which lets you easily
understand its intent and proper use
● Unit tests are the only real measure of project health and code quality
Why not Unit Test

● I never make mistakes

● The functionality is trivial
● Tests slow me down
● Management won’t let me

I don’t know how to test

Properties of a Unit Test
● Isolated
● Repeatable
● Fast
● Self-Documenting
Test Isolation

● No need to build a car to test tries

● Testing payment gateway should not affect my monthly
statement
● It runs faster
Repeatability

● Tests need to be run by every developer, no matter what

stack he/she users
● Tests must not rely on the environment in which they
are being run
Speed

● Time is money, the longer we wait for tests to run, the

more money our clients or company loses
Self-documentation

● Testable code is clear and easy to understand

● No need to explain how a certain component works,
they can just look at the test
● No need to write documentation
Decouple components

Property 1: Isolation
Dependency Injection

“... a technique for decoupling highly dependent

software components”

– wikipeadia.org
DI: Hidden Dependency
DI: Single Responsibility Principle
DI: Why

● Testable code
● No hidden dependencies = Better API = Maintainability
● All common initialization logic an be extracted

What to avoid:
● Long method call chains
Law Of Demeter

Method Call Chains are bad

Law Of Demeter

“Each unit should have only limited knowledge about other

units: only units closely related to current Unit”

“Each unit should only talk to its friends; don’t talk to

strangers”

“Only talk to your immediate friends”

– wikipeadia.org
Law of Demeter
Law of Demeter
Law of Demeter
Control the interaction
Property 2: Speed
Property 3: Repeatability
Test Doubles

“... it may be necessary to use objects or

procedures that look and behave like their
release-intended counterparts, but are actually
simplified versions that reduce the complexity
and facilitate testing. A test double is a generic
(meta) term used for these objects or procedures”

– wikipeadia.org
Types of Test Doubles
● Dummy objects – are passed around but never
actually used.
● Fake objects – usually have working
implementations, but usually take some shortcut.
● Stub objects – provide canned answers to calls
made during the test, usually not responding at
all to anything outside what’s programmed in for
the testing.
● Mock objects – are pre-programmed with
expectations which form a specification of the
calls they are expected to receive.
Mock Objects
Mock Objects
Mock Objects
Mock Objects
Mock Objects