Effective Unit Testing

Effective Unit Testing
Objects, Dependencies and Mocks

@npathai on GitHub
Narendra Pathai
Developing high performance systems,
Software Craftsman, Trainer & Mentor

Unit Test = Test per class
We can choose as small or as large a unit
/

Coverage = Good Tests
If there is no assertion, coverage is of no use!!!
/

Unit Testing = Slow Development
We fail constantly and are extremely slow
when learning anything, does it mean we are
still slow?!
/

No place for excuses
Think of learning to walk, talk, typing!

Must see test case failing once
If a test case hasn’t failed even once, how do
you know it is EVEN checking something?

Web of Objects
● Communication patterns are set of rules
● Rules govern roles they play, what messages they
can send and when
● Communication patterns gives meaning to possible
relationships among objects

Web of Objects
● Either the object returns value to the caller
● Either the object changes it’s state
● Either it interacts with other object via message
passing
● Makes an external call that changes state of that
system such as database call, web service call etc.

Calculator Display
add(int, int)
subtract(int, int)
show(int)
clear()
currentValue()
calls
SYSTEM UNDER
FOCUS
COLLABORATOR
INTERACTIONS
calls
int int
MESSAGES
CLIENT

Web of Objects
● set.add(val)
○ Adds value to the set (change of state)
○ Returns boolean (message passing)
● list.clear()
○ Clears all elements (change of state)
○ Doesn’t return any value (no message passing)
○ Need to call additional methods to verify
behavior eg. size(), isEmpty()

Web of Objects
● observable.notifyObservers()
○ Neither returns any value (no message
passing)
○ Nor does it change any state
○ It interacts with other objects/observers and
passes message to those objects

Testing Units in Isolation
TEST
TEST
?
?
?
?
Mocks
Seam
TEST
Real
Unit under test
Internal
Structure

Finding relationship
between objects
Dependencies/
Collarborators
Message passing/
Notiﬁcation

Veriﬁcation Strategies
STATE
VERIFICATION
BEHAVIOR
VERIFICATION

State Veriﬁcation
A
B
C
SETUP
ACT
VERIFY
TEARDOWN
Exercise
System Under
Test (SUT)
sut.method(..)
Get State
sut.getState()
!
?
Indirect
Output
Real
Mock
Collaborators
Credit: xUnit Test Patterns

State Veriﬁcation
ArrayList<Integer> list = new ArrayList<>();
// Exercise the system under test
list.add(1);
// State verification - verify list is no
more empty
assertFalse(list.isEmpty());

State Veriﬁcation
// Create a new thread
Thread t = new Thread(() -> {});
// State verification - Verify it is in NEW
state
assertThat(t.getState(),
is(equalTo(Thread.State.NEW)));

Behavior Veriﬁcation
● How to test if SUT does not have any state?
● How to test if SUT does not change state?

When SUT does not change state or return value or
cause any visible side effect, it MUST interact with
other object or component.
We can test that interaction!

A
B
C
SETUP
ACT
VERIFY
TEARDOWN
Exercise
SUT
sut.method(..)
?
Indirect
Output
Real
Mock
Collaborators
!
!
!
Seam Credit: xUnit Test Patterns

● Places where we can alter system ﬂow
● Essentially polymorphism (ideally interfaces)
● Allow us to isolate SUT when unit testing
● Procedural code (static) has no seams
● Difﬁcult to test procedural code
SEAM
Not all procedural code is bad! Eg. static utilities like
Math.abs(), Math.max() etc.

WeatherObservable observable = new WeatherObservable();
WeatherObserver observer = new WeatherObserver();
observable.addObserver(observer);
// exercise the SUT
observable.setWeather("FALL");
// Verify that observer was notified
// How to verify that?

Behavior Veriﬁcation Strategies
MANUAL
VERIFICATION
MOCKING
LIBRARY

Manual Behavior Veriﬁcation
// A test specific observer that tracks if method
was called
class TestObserver implements Observer {
private boolean called = false;
@Override
public void update(Observable o, Object arg) {
this.called = true;
}
}

// Custom hand rolled observer
TestObserver observer = new TestObserver();
observable.addObserver(observer);
// exercise the SUT
observable.setWeather("FALL");
// Manual behavior verification
assertTrue(observer.called);

How to test the following:
● Observer should only be called once
● Observer should be called with exact argument

// A test specific observer that tracks if method
was called
class TestObserver implements Observer {
private int count = 0;
private Object arg;
@Override
public void update(Observable o, Object arg) {
this.count++;
this.arg = arg;
}
}

// Manual behavior verification
// Test Readability suffering
assertEquals(1, observer.count);
assertEquals("FALL", observer.arg);

How to test the following:
● Any one of multiple methods should be called
● Different methods called with different arguments
● Observers should be called in exact order in which
they were added
● Many more advanced veriﬁcations..

We are already starting to add logic in test code
itself!! So there is a possibility that test code has
bugs.
Me: So now should we write test cases for test
code?!
Your reaction: That ain’t happening!

1. Complicates test logic
2. Need to repeat it for
all classes
3. Time consuming and
error prone
4. Test readability
suffers
MOCKING
LIBRARY

Features
STUBBING
EXPECTATION
VERIFICATION

Stubbing
● Providing hard-coded
answers/behaviors from
methods called during test
● Test case wise
answer/behavior can be
changed
● Stubbing logic MUST be
simple
For instance:
● Returning a test/dummy user
from DAO layer
● Throwing exception from
DAO layer to replicate error
scenario
a.k.a Training phase

Exp. Veriﬁcation
● Verify how the SUT should
have interacted with its
collaborators
● Verify the communication
contract between SUT and its
collaborators
● MUST be present in every
test case
For instance:
● Verify Observer#update()
method was called once only
● Verify argument was
matching
● Verify Observers were called
in order they were added
a.k.a assertion phase

Mocks
Stubs
Stubbing + Verification
Hard-coded results
No verification
Fakes
Working but simplified version of
production code, like DAO using
collection rather than DB
Dummy
Objects passed around but never
actually used

Fake
a working simpliﬁed version
LoginService
AccountDAO
FakeAccountDAO HashMap
Fake
implementation
login(user)
getPasswordHash()
DB

Stub
object trained with predeﬁned data
GradesService Gradebook
averageGrades(student)
DB
getGrades(student)
OOP: 8
FP: 6
DB: 10
Stub of grades
system

Mock
objects that register calls they receive
SecurityCentral
DoorMock
WindowMock
securityOn()
close()
close()
Action to verify

Mockito
EasyMock
JMock
PowerMock
Mocking Libraries

LEARNING MOCKITO
A basic primer

Mockito code samples are given only for learning
purposes and don’t necessarily reﬂect good
practices. We will mock Java library classes for
learning purposes but it is not recommended to
mock third party classes.
Warning

Creating Mock
@Test
@SuppressWarnings("unchecked")
public void creatingAMockUsingMockMethod() {
List<String> mockedList = Mockito.mock(List.class);
assertThat(mockedList, is(notNullValue()));
}
Using mock method

Creating Mock
// Rule will automatically init mocks which have
annotation
@Rule public MockitoRule mockito = MockitoJUnit.rule();
@Mock private List<String> mockedList;
@Test
public void creatingAMockUsingRule() {
// Mock will already be created for use
assertThat(mockedList, is(notNullValue()));
}
Using rule

Veriﬁcation
@Test
public void simpleVerification() {
// perform some interactions, mock remembers all
mockedList.add("one");
mockedList.clear();
// Verification of interactions, selectively
Mockito.verify(mockedList).add("one");
Mockito.verify(mockedList).clear();
}

Stubbing
@Test
public void simpleStubbingReturnValueFromMethod() {
// Stubbing or training the mock
Mockito.when(mockedList.get(0)).thenReturn("one");
// Using the stubbed mock
assertThat(mockedList.get(0), is(equalTo("one")));
// Because we have not trained the mock to expect
argument 1
assertThat(mockedList.get(1), is(nullValue()));
}
Returning value from method

Stubbing
@Test
public void stubbingExceptionFromMethod() {
// Train mocked list to throw exception when called
with argument 1
Mockito.when(mockedList.get(1)).thenThrow(
new RuntimeException("Stubbing exception"));
exception.expect(RuntimeException.class);
exception.expectMessage("Stubbing exception");
mockedList.get(1);
}
Throwing exception from method

Stubbing
@Test
public void stubbingExceptionFromVoidMethod() {
Mockito.doThrow(RuntimeException.class)
.when(mockedList).clear();
exception.expect(RuntimeException.class);
mockedList.clear();
}
Throwing exception from void method

Veriﬁcation
@Test
public void verifyExactNumberOfInvocations() {
mockedList.add("two"); mockedList.add("two");
mockedList.add("three"); mockedList.add("three");
mockedList.add("three");
// verify exact invocations
Mockito.verify(mockedList).add("one"); // default is 1 time
Mockito.verify(mockedList, Mockito.times(1)).add("one");
Mockito.verify(mockedList, Mockito.times(2)).add("two");
Mockito.verify(mockedList, Mockito.times(3)).add("three");
}
Exact number of invocations

Veriﬁcation
@Test
public void verifyAtleastOrAtmostInvocations() {
mockedList.add("two"); mockedList.add("two");
mockedList.add("three"); mockedList.add("three");
mockedList.add("three");
// verify atleast or atmost invocations
Mockito.verify(mockedList, Mockito.atLeastOnce()).add("two");
Mockito.verify(mockedList, Mockito.atLeast(2)).add("three");
Mockito.verify(mockedList, Mockito.atMost(5)).add("three");
}
Atleast or At-most invocations

Veriﬁcation
@Test
public void verifyNeverInvocations() {
// verify never invocations
Mockito.verify(mockedList, Mockito.never()).add("two");
Mockito.verify(mockedList, Mockito.never()).add("three");
}
Never invocation

Veriﬁcation
@Test
public void verifyInorderInvocationWithSingleMock()
{
mockedList.add("added first");
mockedList.add("added second");
InOrder inOrder = Mockito.inOrder(mockedList);
inOrder.verify(mockedList).add("added first");
inOrder.verify(mockedList).add("added second");
}
In order invocations (single mock)

Veriﬁcation
@Test
public void verifyInorderInvocationWithMultipleMocks() {
firstMock.add("first");
secondMock.add("second");
thirdMock.add("third");
// Not necessary to include all mocks
InOrder inOrder = Mockito.inOrder(firstMock, thirdMock);
inOrder.verify(firstMock).add("first");
inOrder.verify(thirdMock).add("third");
}
In order invocations (multiple mocks)

Mockito Behavior Veriﬁcation
observable.addObserver(mockObserver1);
// Winter is coming :P
observable.setWeather("WINTER");
verify(mockObserver1).update(observable, "WINTER");

LEARNING MOCKITO
A basic primer
END OF

compared
1. Complicates test logic
2. Need to repeat it for
all classes
3. Time consuming and
error prone
4. Test readability
suffers
1. No test logic
2. No repetition
3. Only time consumed
is to learn the library
4. Test readability
greatly improved

F.I.R.S.T Principle
FAST
ISOLATED/INDEPENDENT
REPEATABLE
SELF-VALIDATING
THOROUGH

Fast
Developer should not hesitate to run tests
Thousands of tests per minute

Independent/Isolated
No dependency on other test
Order should not matter
Each test should leave system in clean state

Repeatable
No dependency on external environment such
as Randomness, System time
Tests must fail with same reason on multiple
execution

Self-Validating
Each test MUST have an assertion
No manual inspection needed to verify results

Thorough
Test for scenarios not coverage (please!!!)
Test business logic not setters/getters
Exceptional scenarios such as DB
connectivity failure, timeout, invalid input

Dependency Injection
Not all injections have to be painful!

Thermostat Example
Please refer to source code for Thermostat1
As a factory inspector, I want a thermostat, so that I can set
target temperature for my machines and log on console if
temperature ﬂuctuates to too high or low levels
Requirement

Alert
Log alert on
console
Detect temperature
using Chip121
hardware
Naive Example
<<creates>>
<<creates>>
Thermostat
Chip121TemperatureSensor
Log alerts when
temperature
ﬂuctuates away
from target
temperature

Naive Example
public Thermostat1(double targetTemperature) {
this.targetTemperature = targetTemperature;
// Taking decision of type of sensor by itself
this.sensor = new Chip121TemperatureSensor();
this.alert = new Alert();
}

Thermostat Example
As a factory inspector, I want a thermostat, so that I can set
target temperature for my machines using sensor and log
on console if temperature ﬂuctuates to too high or low
levels
Requirement

Thermostat Example
As a thermostat manufacturer, I want the thermostat to be
able to use different sensors because some newer
thermostat models are better at sensing temperature.
Requirement

Naive Example
Currently we can’t reuse because
● Thermostat1 creates sensor from constructor
leaving us helpless if we wan’t to choose other sensor
● There is no interface for sensor

Naive Example
Alert
Log alert on
console
Detect temperature
using Chip121
hardware
<<creates>>
<<creates>>
Thermostat Chip121TemperatureSensor
Directly creates
concrete class
Log alerts when
temperature
ﬂuctuates away
from target
temperature

Extract Interface
Detect temperature
using Chip121
hardware
Detect temperature
using some hardware
<> TemperatureSensor
Detect temperature
using XYZ hardware
XYZTemperatureSensor

Use interface
Detect temperature
using some hardware
<<creates>>
Thermostat <> TemperatureSensor
Log alerts when
temperature
ﬂuctuates away
from target
temperature
Directly creates
concrete class
Chip121TemperatureSensor XYZTemperatureSensor
Interface is deﬁned

Detect temperature
using some hardware
<<depends>>
Thermostat <> TemperatureSensor
Log alerts when
temperature
ﬂuctuates away
from target
temperature
Chip121TemperatureSensor XYZTemperatureSensor
Interface is deﬁned and
dependency is injected
via constructor

// Dependency
private final TemperatureSensor sensor;
Thermostat2(double targetTemperature,
TemperatureSensor sensor) {
this.targetTemperature = targetTemperature;
this.sensor = sensor;
...
}

When constructing objects, the act of connecting
objects with other objects, or “injecting” objects into
other objects. It is the “D” in S.O.L.I.D principles.
● Constructor Injection (preferred way)
● Field Injection (way frameworks do it using
annotation)
● Method injection (using setters)

new Thermostat2(24, new Chip121TemperatureSensor(),
...);
new Thermostat2(24, new XYZTemperatureSensor(),
...);
Injecting the sensor

Naive Example
As a air conditioner manufacturer, I want to control
compressor and heater using thermostat, so that I can
maintain room temperature by switching on/off
heater/compressor
Requirement

Naive Example
Currently we can’t reuse because
● Thermostat2 creates Alert which can only log to
console
● There is no interface for alert mechanism

if (tooCold(temperature)) {
alert.temperatureTooLow(temperature);
}
Naive Example
Here alert is not a dependency. But rather a notiﬁcation that it
needs to send to some other objects. Just like Observer pattern.
Observer entities will react to that notiﬁcation and apply custom
business logic like logging to console, controlling compressor or
heater

Extract Interface
Log temperature
fluctuations to console
ConsoleAlert
Callback to receive
temperature
fluctuation events
Switch on/off controller
based on temperature
fluctuation
CompressorController
<> TemperatureListener
...

Use Interface
<<creates>>
Thermostat <> TemperatureListener
Log alerts when
temperature
fluctuates away
from target
temperature
Directly creates
concrete class
ConsoleAlert CompressorController
Interface is defined
Callback to receive
temperature
fluctuation events

Open for extension
<<notifies>>
Thermostat <> TemperatureListener
Notifies when
temperature
fluctuates away
from target
temperature
ConsoleAlert CompressorController
Interface is defined &
multiple receivers
Callback to receive
temperature
fluctuation events
*
1
...

Refactored Naive
Example
<<depends>>
Thermostat
<>
TemperatureSensor
Notifies when
temperature
fluctuates away
from target
temperature
Chip121... XYZ...
<>
TemperatureListener
Console... Compressor...
<<notifies>>
1
*
...
...
Seam

Refactored Naive
Example
Thermostat3 thermostat5 = new Thermostat3(24,
temperatureSensor);
thermostat5.addListener(new HeaterController());
thermostat5.addListener(new CompressorController());

Thermostat Example
As a air conditioner manufacturer, I want to control
compressor and heater using thermostat, so that I can
maintain room temperature by switching on/off
heater/compressor
Requirement

TESTS
are ﬁrst client of your code
Assume previous requirements were given by Unit tests

Naive Example
As a unit test
1) I want to use mock sensor as actual chipset cannot be
used in unit testing
2) use mock listener as heater or compressor will not be
available in unit testing and mocking sysout is not a
good option
Requirement

Testable Naive Example
<<depends>>
Thermostat
<>
TemperatureSensor
<>
TemperatureListener
<<notiﬁes>> 1
*
Seam
Mocks (controlled by tests)

Refactored Naive
Example
@Test
public void generatesTooHotAlertIfTempratureExceedsTargetTemperatureThreshold()
{
when(mockSensor.getReading()).thenReturn(24.11);
thermostat.addListener(mockListener);
...
verify(mockListener).onTemperatureTooHigh(24.11);
}

Observations
● Unit testing makes code loosely coupled
● If we started with the goal of unit testing then our code naturally
becomes reusable
● Isolating System Under Test requires Seam
● Improves design of your units (not always)

Thermostat Example
As a unit test
1) I want to use mock sensor as actual chipset cannot be
used in unit testing
2) use mock listener as heater or compressor will not be
available in unit testing and mocking sysout is not a
good option
Requirement

Dealing with Randomness
Math.random() or new Random() etc

Naive Example
As a lucky game player, I want a game of dice so that I can
play the game to test my luck and win rewards.
We will roll dice thrice and if dice has face value 6 all th
then user will get reward.
Requirement

Randomness Example
Please refer to source code for DiceOfFortuneGame
public class DiceGame {
private Random random = new Random();
/**
* Rolls dice three times and returns result. Game can be won if dice value
is equal to 6.
*/
public boolean rollDice() {
return isLucky() && isLucky()
&& isLucky();
}
private boolean isLucky() {
return roll() == 6;
}
}
private int roll() {
return random.ints(1, 7)
.findFirst().getAsInt();
}

Source of
unpredictable random
value
<<creates>>
DiceGame java.util.Random
Roll dice and
return result of
the game
Randomness Example

Randomness Example
public class DiceGameTest {
private DiceGame game = new DiceGame();
// Coverage yes but no good as no assertion
@Test
public void testNoException() {
boolean unpredictableResult = game.rollDice();
// We cannot predict whether game is working or not
because it is using random value and we cannot control it.
System.out.println(unpredictableResult);
}
}

java.unit.Random
Source of
unpredictable
random value
Refactored Randomness Example
<<depends>>
Roll dice and return
result of the game
DiceGame
Seam
Constructor
Injection

public class DiceGame {
private Random random;
DiceGame(Random random) {
this.random = random;
}
public boolean rollDice() {
return isLucky() && isLucky() && isLucky();
}
private boolean isLucky() {
return roll() == 6;
}
}

@Mock(answer = Answers.RETURNS_DEEP_STUBS)
private Random mockRandom;
@InjectMocks
private DiceGame game;
@Test
public void gameIsWonIfThreeConsecutiveRollsOfDiceFaceShows6() {
Mockito.when(mockRandom.ints(Mockito.anyInt(), Mockito.anyInt())
.findFirst()).thenReturn(of(6));
boolean result = game.rollDice();
assertTrue(result);
verify(mockRandom.ints(1, 7),
times(3)).findFirst();
}

Randomness Example
As a lucky game player, I want a game of dice so that I can
play the game to test my luck and win rewards.
We will roll dice once and if dice face has value greater
than 3 then user will get reward.
Requirement

Detect temperature
using Chip121
hardware
java.util.Random
Source of
unpredictable
random value
Randomness Example
<<creates>>

Randomness Example
class Chip121TemperatureSensor {
// Creating random makes tests unpredictable
private Random random = new Random();
private double getReading() {
return random.doubles(targetTemperature - 1.0,
targetTemperature + 1.0).findFirst().getAsDouble();
}
}

Randomness Example
Constructor Injection of Random
If we mock Random, we violate
○ Don’t mock classes you don’t own
■ Ugly to mock Connection, PreparedStatement
○ “Mock interfaces only” ( unless testing legacy code)

Extract Interface
Provide Random value
using java library
SystemRandomProvider
Source of
unpredictable random
value
Provide ﬁxed value on
each call
(for testing only)
FixedRandomProvider
<> RandomProvider
...

Random
Provider
Source of
unpredictable
random value
<<depends>>
Detect temperature
using Chip121
hardware
Chip121Temperature Sensor
FixedRandom
Provider
SystemRandom
Provider
Seam

class Chip121TemperatureSensor {
private RandomProvider randomProvider;
private double getReading() {
return randomProvider.nextDouble(targetTemperature - 1.0,
targetTemperature + 1.0);
}
}

@Test
public void
sensorGeneratesTemperatureWithinPlusOrMinusOneRangeOfTargetTemperature() {
sensor.getReading();
// Tests are incomplete without this assertion. Why?
verify(fixedRandomProvider, times(1)).nextDouble(TARGET_TEMPERATURE - 1.0,
TARGET_TEMPERATURE + 1.0);
}
@Test
public void returnsTheCurrentTemperatureReading() {
fixedRandomProvider.setRandom(24);
assertThat(sensor.getReading(), is(equalTo(24.0)));
}

Dealing with
Asynchronous code
Thread or ExecutorService or ScheduledExecutorService

Read Sensor data
Every Seconds
Thread Example
<<creates>>
Thread.sleep(1000)
Thermostat
Thread
Log alerts when
temperature
ﬂuctuates away
from target
temperature
<<call>>

public Thermostat3(double targetTemperature) {
...
// Creates thread which makes it difficult to test
new Thread(() -> {
while (!Thread.interrupted()) {
sleep();
setCurrentTemperatureReading(sensor.getReading());
}
}).start();
}
Thread Example

@Test
public void test() throws InterruptedException {
Thermostat3 thermostat1 = new Thermostat3(24);
Thread.sleep(2000); // Wait till first reading is taken
double temperature = thermostat1.getCurrentTemperature();
...
}
Thread Example
Caution: Slow Tests!!

Thread Example
Currently Thermostat is hard to test
● Thermostat creates thread in constructor
● Test case is hard to debug as sensor reading performed
in separate Thread
How make Thermostat testable??

Thread Example
Run Task in separate
Thread using Java
Executor API
DefaultTaskScheduler
Run the task at regular
interval
Provide control over
scheduled task by
capturing the task
FakeTaskScheduler
<> TaskScheduler
...

Task Scheduler
Run the task at
regular interval
Refactored Thread Example
<<depends>>
Schedule the task
which read sensor
data every 1 sec
Thermostat
DefaultTaskSched
uler
FakeTaskSched
uler
Seam

Thermostat4(double targetTemperature, RandomProvider
randomProvider, TaskScheduler taskScheduler) {
this.taskScheduler = taskScheduler;
// Does not manage thread itself but depends on task
scheduler to do the job
taskScheduler.scheduleFixedDelayTask(() ->
setCurrentTemperatureReading(sensor.getReading()),
1, TimeUnit.SECONDS);
}

@Test
public void generatesTooHotAlertIfTempratureExceedsTargetTemperatureThreshold(){
when(mockSensor.getReading()).thenReturn(24.11);
// Run the scheduled task in sync (current thread only)
fakeTaskScheduler.tick();
verify(mockListener).onTemperatureTooHigh(24.11);
}

@Test
public void test1() {
new DreadfulController().doSomething();
}
@Test
public void test2() {
}
Will these tests pass?

@Test
public void thisTestMayFail() {
}
@Test
public void thisTestMayFailToo() {
}
Any test can fail
randomly
Why?

@Test
public void thisTestMayFail() {
}
@Test
public void thisTestMayFailToo() {
}
Any test can fail
randomly
Hidden static
static
variable

Hidden static
DreadfulController
calls
DreadfulDependency
DreadfulHelper
calls
static
static
variable
uses
Indirectly
uses
DreadfulController
DreadfulController DreadfulDependency
DreadfulDependency

Hidden Global State
public class DreadfulHelper {
private static int globalEvilState = 0;
public static void doDreadfulStuff() {
if (++globalEvilState % 2 == 0) {
throw new RuntimeException("Global evil
hidden state will haunt you forever!");
}
}
}

Global State is Evil!
(static variables)

Solution: Global State
You control the state not the class
DreadfulController
calls
PleasantHelper
calls
instance
variable
uses
Use same instance of
dependency in
production and
different in test
DreadfulController
PleasantController PleasantDependency

Test code
@Before
public void createController() {
//Fresh clean copy of PleasantHelper for each test
controller = new PleasantController(new PleasantDependency(
new PleasantHelper()));
}
@Test
public void thisTestCannotFailAsItIsIsolated() {
controller.doSomething();
}
@Test
public void thisTestCannotFailAsItIsIsolatedToo() {
controller.doSomething();
}

Production code
PleasantHelper sharedHelper = new PleasantHelper();
PleasantDependency pleasantDependency
= new PleasantDependency(sharedHelper);
PleasantController controller1
= new PleasantController(pleasantDependency);
PleasantController controller2
= new PleasantController(pleasantDependency);
controller1.doSomething();
// will throw exception because of shared PleasantHelper
controller2.doSomething();

Controlled shared state
● Don’t enforce global state by using static variables
● Use shared state to mimic global state
● Responsibility of maintaining shared state is on the
objects that create and weave objects together like
Factories or Mother classes

● Unpredictable test results (ﬂaky)
○ Reduces conﬁdence in tests
● Test order affects test results
○ Some test may change state which affects other test
● Issues in running tests in parallel
○ Different test threads affect same state
Global State Issues

Singleton Pattern
a curious case of global state

Singleton example
BadUserController
Processes user
request and
alerts if
processing
takes time
SNMPService ConﬁgurationManager
snmp-servic
e.xml
snmp-servic
e.xml
snmp-servic
e.xml
Socket
<<depends>>
static call to
getInstance()
Singleton Singleton
<<opens>> <<reads>>
External world
static call to
getInstance()

Singleton example
BadUserController
Processes user
request and
alerts if
processing
takes time
snmp-servic
e.xml
snmp-servic
e.xml
snmp-servic
e.xml
Socket
<<depends>>
static call to
getInstance()
Singleton Singleton
<<opens>> <<reads>>
External world
static call to
getInstance()
Unintentional baggage
Unintentional
baggage

Singleton example
An ugly attempt to test
UserRequest userRequest = newUserRequest();
User user = new User();
user.setFirstName(TEST_USER_NAME);
user.setId(userRequest.getUserId());
...
ConfigurationManager.getInstance().init();
// Tries to establish connection to SNMP service
SNMPService.getInstance().init();
controller.processUserRequest(userRequest);
// Can't really test this now because its tightly coupled
with SNMP

Singleton = Global State
● Uses a static variable hence global state (isolation issue)
● Can only be accessed via static method (Seam issue)
● Not all singletons are evil, we need singletons but not as
frequently as we use
● Don’t use Singleton only to increase scope of object, so that
anywhere in the code we can use it
Makes code difﬁcult to test

Singleton example
if (TimeUnit.MILLISECONDS.toSeconds(end - start) > 1) {
SNMPService.getInstance().generateAlert("User lookup
operation took more than 1 sec");
}
● Creating SNMP connection is not feasible in unit test
● Static call means procedural code
● No Seam available to test
How to solve this?

Singleton example
Inject Singleton
BadUserController
Processes user
request and
alerts if
processing
takes time
snmp-servic
e.xml
snmp-servic
e.xml
snmp-servic
e.xml
Socket
<<depends>>
Singleton Singleton
<<opens>> <<reads>>
External world
static call to
getInstance()
Real
implementation
MockSNMPServic
e
Constructor
Injection
Constructor
Injection
Test code

Refactored Singleton example
<<depends>>
<> AlertService
SNMPService MockAlertService
Interface is deﬁned &
dependency injection
Service that can
generate alert
1
...
GoodUserController
Processes user
request and
alerts if
processing
takes time
1
Test code uses

Refactored Singleton example
Hows tests should look like
controller = new GoodUserController(.., mockAlertService, ..);
… Some more test training code here
// Exercise SUT
controller.processUserRequest(userRequest);
verify(mockAlertService).generateAlert("User lookup operation
took more than 1 sec");

Isolating
System.nanoTime()
or
System.currentTimeInMillis()
Or
LocalDate (Java8)
a special case of global state

Time dependency example
long start = System.nanoTime();
User user = userRepository.getUser(request.getUserId());
long end = System.nanoTime();
if (TimeUnit.MILLISECONDS.toSeconds(end - start) > 1) {
// Generate alert
}
How to test alert scenario?

Mockito.doAnswer(invocationOnMock -> {
// Introduce real delay, make tests slower! Yayy
Thread.sleep(2000);
return user;
}).when(mockHibernateRepository)
.getUser(Mockito.anyString());
A naive attempt - Thread.sleep()

Introducing real delay with Thread.sleep() makes tests slower
Problems with naive attempt
Few tests with
Thread.sleep()
Ain’t that bad!
Add a few more to
the mix
Tests take 4-5 mins
Becomes a habit!
Well it’s all right.
Tests take 20 mins
Few sprints later
Tests take hours!
Why is build so
slow?
Dev: “Tests take too
long. Can’t check it
everytime I change
something”
Somebody: “Build is
too slow, let’s skip
unit tests. Anyway
they don’t add
value”
Doomsday strikes

Peppering threading logic in tests
● Makes them harder to read and understand
○ Like production code wasn’t enough
● Makes them ﬂaky/unpredictable
○ Cause yeah getting threading right is so easy!
Right?
Problems with naive attempt

SystemTicker MockTicker
Abstracting System.nanoTime()
<> Ticker
Source for fetching
elapsed time
+ nanoTime()
SystemUnderTest
<<depends>>
long start =
ticker.nanoTime();
User user =
userRepository.getUser(request
.getUserId());
long end = ticker.nanoTime(); return System::nanoTime; // returns what you want

SystemTimeSource MockTimeSource
Abstracting System.currentTime...
<> TimeSource
Source for fetching
clock time
+ currentTimeInMillis()
SystemUnderTest
<<depends>>
long time =
timeSource.currentTimeInMillis();
return System::currentTimeInMillis; // returns what you want

LocalDate dependency example
public DiwaliPromotionFactory1(
DiwaliDayProvider diwaliDayProvider) {
this.diwaliDayProvider = diwaliDayProvider;
}
public DiwaliPromotion get() {
LocalDate now = LocalDate.now();
// Calculate which day will be Diwali this year
LocalDate diwali = diwaliDayProvider.get(now.getYear());
return new DiwaliPromotion(diwali.atStartOfDay());
}
How to test?

@Test
public void locatesCurrentYearDiwaliDay() {
DiwaliPromotionFactory1 factory =
new DiwaliPromotionFactory1(mockDiwaliDayProvider);
factory.get();
// Well works all well in 2018, but starts failing in 2019
verify(mockDiwaliDayProvider).get(2018);
}
Bad Attempt - Ticking time bomb

public DiwaliPromotionFactory2(DiwaliDayProvider diwaliDayProvider,
Clock clock) {
this.diwaliDayProvider = diwaliDayProvider;
this.clock = clock;
}
@Test
public void locatesCurrentYearDiwaliDay() {
Clock fixedClock = newFixedClockAt(FIXED_DATE);
DiwaliPromotionFactory2 factory =
new DiwaliPromotionFactory2(mockDiwaliDayProvider, fixedClock);
factory.get();
// Because date is fixed, tests will always pass
verify(mockDiwaliDayProvider).get(FIXED_DATE.getYear());
}
Inject Clock instance

Object Creation Is A
Responsibility
How To Think About new Operator

Credit Card Processing Example
AuthenticatorPage
R
ChargePage
R
Authenticator
S
CreditCardProcessor
S
UserRepository
S
OfﬂineQueue
S
Database
S
S - Singleton scope
R - Request scope
Constructor
Collaborator
Same construction and collaboration graph
Credit: Miško Hevery

Same construction and collaboration graph
● Difﬁcult to test as each object is creating the objects it
needs (it’s ok to create value objects or internal
helpers)
● new operator is scattered all around the codebase
● It’s not the responsibility of business objects to create
objects via new or via getInstance (indirectly new)

S - Singleton scope
R - Request scope
Constructor
Collaborator
With Dependency Injection
AuthenticatorPage
R
ChargePage
R
Authenticator
S
CreditCardProcessor
S
UserRepository
S
OfﬂineQueue
S
Database
S
ApplicationFactory
(Singleton lifetime)
S
RequestFactory
(HTTP Request Lifetime)
S

● The construction (instantiation) of objects is moved to
Factory classes which is where majority of new
operator is located
● Object construction is separated from collaboration
graph
● ApplicationFactory creates all singleton scope
objects
● RequestFactory creates all request scope objects and
depends on singleton scope objects

// All objects created by application factory are singleton in scope.
public class ApplicationFactory {
private RequestFactory requestFactory;
public void build() {
// leaf of graph has no dependency, so gets created first
Database database = new Database();
OfflineQueue offlineQueue = new OfflineQueue(database);
Authenticator authenticator = new Authenticator(database);
UserRepository userRepository = new UserRepository(database);
CreditCardProcessor creditCardProcessor = new CreditCardProcessor(offlineQueue);
requestFactory = new RequestFactory(authenticator, userRepository,
creditCardProcessor);
}
public RequestFactory getRequestFactory() {
return requestFactory;
}
}

// All objects created by request factory are HTTP request scope.
public class RequestFactory {
private final Authenticator authenticator;
private final UserRepository userRepository;
private final CreditCardProcessor creditCardProcessor;
public RequestFactory(Authenticator authenticator, UserRepository userRepository,
CreditCardProcessor creditCardProcessor) {
this.authenticator = authenticator;
this.userRepository = userRepository;
this.creditCardProcessor = creditCardProcessor;
}
public AuthenticationPage build() {
return new AuthenticationPage(authenticator,
new ChargePage(creditCardProcessor, userRepository));
}
}

Show of hands
How many of you feel with time it gets
difﬁcult to add new features to existing code?

Show of hands
How many of you want to change structure of
code to make it easier to add new feature but
can’t do because lack of understanding of
code or lack of conﬁdence?

Refactoring
Make small changes to code without affecting
the overall behavior of the visible behavior of
software

“First make the change easy,
then make the easy change”
- Kent Beck on Refactoring

Refactoring
Automated Testing
RELIES ON

LEARNING MOCKITO
Few advanced concepts

Stubbing
@Test
public void stubbingReturnValueForAnyArgument() {
// For any index value return "fixed value"
// List will behave as if all indexes have value "fixed
value"
Mockito.when(mockedList.get(Mockito.anyInt()))
.thenReturn("fixed value");
assertThat(mockedList.get(999), is(equalTo("fixed value")));
}
Matching any argument - Argument Matchers

Veriﬁcation
@Test
public void verifyingArgumentUsingArgumentMatchers() {
mockedList.get(987);
// Will test if get() was called with any index argument
Mockito.verify(mockedList).get(Mockito.anyInt());
}
Verifying any argument - Argument Matchers

Argument Matchers
Mockito.anyInt();
Mockito.anyDouble();
Mockito.anyString();
Mockito.anyCollection();
Mockito.anySet();
Mockito.anyObject();
Mockito.any(CustomClass.class);
// Many more
Many built-in and we can create custom

Spies
public class Chip121TemperatureSensorTest {
private static final double TARGET_TEMPERATURE = 24;
@Spy
private FixedRandomProvider fixedRandomProvider = new FixedRandomProvider();
private TemperatureSensor sensor;
@Test
public void sensorGeneratesTemperatureWithinPlusOrMinusOneRangeOfTargetTemperature() {
sensor.getReading();
// Tests are incomplete without this assertion. Why?
verify(fixedRandomProvider, times(1)).nextDouble(TARGET_TEMPERATURE - 1.0,
TARGET_TEMPERATURE + 1.0);
}
Real objects + Mocking

Don’t Verify Your Own Stubbing
Mockito.when(mockedObject.method(1))
.thenReturn("one");
// This only proves that mocking library works
assertThat(mockedObject.method(1),
is(equalTo("one")));
We don’t want to test mocking library

Only verify indirect behavior
Verify how SUT interacted with your mock
observable.setWeather("WINTER");
// Verifying whether mock was indirectly called

Testing Internals
public class Customer {
private CustomerStatus status = CustomerStatus.REGULAR;
public void promote() {
this.status = CustomerStatus.PREFERRED;
}
public double getDisount() {
return this.status == CustomerStatus.PREFERRED ? 0.5 : 0;
}
}
@Test
public void promotingChangesCustomerStatusToPreferred() {
Customer customer = new Customer();
customer.promote();
// Exposing internal state makes tests brittle, what if tomorrow
// we have to refactor and remove enum to use boolean
assertThat(customer.status, is(equalTo(Customer.CustomerStatus.PREFERRED)));
}
Don’t expose internal state just for testing purposes

Testing via Public API
@Test
public void aPromotedCustomerEnjoysDiscountedRate() {
Customer customer = new Customer();
customer.promote();
// Checking for side effect using public API and not
checking
// internal state. So Customer can be refactored to use
boolean
// instead of enum easily without breaking unit tests
assertThat(customer.getDisount(), is(equalTo(0.5)));
}
Allows for easier refactoring

Hidden Dependencies
public class ClassHidingDependency {
public void doSomething() {
try {
// Looking up objects from thin air
Context.getX().getY().getZmanager().init();
Context.getX().getY().getZmanager().doSomething();
} catch (Exception e) {
// No problem somebody else might have called init.
// Eating exception - Yikes!!
}
}
}
Don’t hide dependencies

Explicit Dependencies
public class ClassExplicitDependency {
private final ZManager zManager;
public ClassExplicitDependency(ZManager zManager) {
// zManager instance being passed must be already initialized
this.zManager = zManager;
}
public void doSomething() {
// Directly using ZManager, as it expects an already initialized
object
// to be passed via constructor
zManager.doSomething();
}
}
Perform Dependency Injection

Global State Cleanup - reset
public class ResettableSingleton {
public static final ResettableSingleton INSTANCE = new
ResettableSingleton();
private int doneCount;
private ResettableSingleton() {
}
// Will work when single tests are run, but will fail randomly when
tests are run in parallel
public void reset() {
doneCount = 0;
}
}
Doesn’t really work when tests run in parallel

Singleton → singleton
// Container can ensure only one instance of Lenient
is created. Hence ensuring singleton property
public class Lenient {
private int doneCount;
public Lenient() {
// Not enforcing singletoness, tests can create independent
instances which are isolated from each other
}
}
Don’t enforce singletoness via private constructor

Avoid Threads in Unit Tests
@Test
public void test() throws InterruptedException {
sut.doSomethingInvolvingThreads();
// Don't do this
Thread.sleep(1000);
if (getResult() == null) {
// if result not yet calculated sleep some more
Thread.sleep(1000);
}
Object result = getResult();
// assertion
}
Makes code slower and hard to read and troubleshoot

Inject Non-Threaded ExecutorService
private SystemUnderTest sut =
new SystemUnderTest(MoreExecutors.directExecutor());
@Test
public void test() {
sut.doSomethingInvolvingThreads();
// Result is already available because background work was
performed by current thread
Object result = getResult();
}
Use Guava DirectExecutor or FakeExecutor

Tests for “legacy code” do
look ugly
But ﬁrst it’s important to test and then improve the
legacy code and tests

Develop Custom Test APIs
It’s important that tests are free of repetition, so make
utilities and APIs that others can reuse

Effective Unit Testing

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Effective Unit Testing

Similaire à Effective Unit Testing (20)

Dernier

Dernier (20)

Effective Unit Testing