iOS Test-Driven Development

iOS Test-Driven
Development
Experiencing a new way of working

I’m going to talk about…
• Some definitions
• Some concepts
• Unit Tests
• The TDD cycle
• Some principles
!
• TDD: Pros & Cons
• 3 kind of verifications
• External dependencies
• iOS Tests (practice part!)
• References

Test-driven development (TDD)
is a software development process that relies on the
repetition of a very short development cycle.
!
-
!
Kent Beck, who is credited with having developed or
‘rediscovered' the technique, stated in 2003 that TDD
encourages simple designs and inspires confidence.
–Wikipedia

Test-driven development, or TDD for short, is a simple
software development practice where unit tests, small
focused test cases, drive the development forward.
!
-
!
Test cases are written before any production code.
!
Not all the tests are written up front, it’s rather that a small
test is written, then a small piece of production code is
written that only allows that test to pass.
–jayway.com

TDD is an approach to development that uses automated
software tests to drive the design and development of an
application iteratively.
!
-
!
It pushes the developer to focus on one thing at a time,
and usually one fairly small thing.
–Sunetos, Inc.

The idea behind test-driven development is that it
makes you think about what the code you are writing
needs to do while you are designing it.

As a side effect, we get some safety against breaking
things in the future.
OUR work,
designing & coding

TDD motivates rapid addition of new functionality
to your code, because you are free to make any
change you want to your code and can rapidly
get feedback on whether the change introduced any
problems…

TDD motivates rapid addition of new functionality
to your code, because you are free to make any
change you want to your code and can rapidly
get feedback on whether the change introduced any
problems…
… or not!

A common mistake in any discipline of software
engineering is to only ask about code and test the
“happy path” without specifying or discovering what
happens in case of error.

That IS NOT GOOD.

That IS NOT GOOD.
And, guess what? TDD discourages that.

What is the cost of fixing a defect vs. preventing it?
!
!
!
Learning and implementing TDD at the beginning is
hard.
!
!
!
However, once you make it over the learning curve of
TDD, your time-to-market will be the same, but with
many more benefits.

TDD changes design from a process of invention
to a process of discovery.

where the developer thinks hard about
what a unit code should do and then
implements it

where the developer thinks hard about
what a unit code should do and then
implements it
where the developer adds small increments or
functionality and then extracts structure
from the working code

“Preventing bugs is not a TDD goal. It’s more like a
side effect.”

What is a Unit Test?
A unit test is a piece of code (usually a method) that
invokes another piece of code and checks the
correctness of some assumptions afterwards.
A unit test must test a single unit of code, which is
usually a method or function within a class.

What is a Unit Test?
If assumptions turn out to be wrong, the test has failed.
Otherwise, the test has passed.
Unit testing will be performed against
a System Under Test (SUT).
Tests SUT

Properties of a Unit Test
Any unit test should have the following properties:
❖ It should be automated and repeatable.
❖ It should be easy to implement.
❖ Once it’s written, it should remain for future use.
❖ Anyone should be able to run it.
❖ It should run quickly.

UNIT
TESTS INTEGRATION
TESTS
❖ Verify
that
a
relatively
small
piece
of
code
is
doing
what
is
intended
to
do
!
❖ Narrow
in
scope
!
❖ Easy
to
write
and
execute
!
❖ Intended
for
the
use
of
the
programmer
!
❖ Testers
and
users
downstream
should
benefit
from
seeing
less
bugs
!
❖ Done
in
total
isolation
❖ Demonstrate
that
different
pieces
of
the
system
work
together
!
❖ Can
cover
whole
applications
!
❖ Require
more
effort
to
put
together
!
❖ Intended
for
the
use
of
non-‐programmers
!
❖ Their
output
is
the
integrated
system
ready
for
System
Testing
!
❖ Done
altogether
(taken from my previous talk about KIF Integration Tests)

Unit tests are usually composed by 3 parts:
1. Preparation
// given
these initial conditions…
// when
I execute this code…
// then
I expect this to happen…
2. Execution
3. Verification

Unit tests are usually composed by 3 parts:
// given
Counter *counter = [[Counter alloc] init];
[counter setCount:3];
// when
[counter increment];
// then
XCTAssertTrue(counter.count == 4, @“3 incremented should
give us 4”);

Write a
failing test
Write
the simplest
code to pass
the test

Write a
failing test
Write
the simplest
code to pass
the test
Refactor!
to make code
clean

To make sure we are adding
Write a
failing test
something new
Write
the simplest
code to pass
the test
Refactor!
to make code
clean
Both testing and
production code
KISS

Write a
failing test
To make sure we are adding something
new
- (void)testOneIncrementedShouldYieldTwo
{
// given
Counter *counter = [[Counter alloc] init];
[counter setCount:1];
!
// when
[counter increment];
!
// then
XCTAssertEqual(counter.count, 2, nil);
}
1.
Tests SUT

Write a
failing test
new
@implementation Counter
!
- (void)increment
{
!
}
!
@end
1.
Tests SUT

Write a
failing test
new
!
- (void)increment
{
!
}
!
@end
Leaving this method empty we will
make the test fail.
1.
Tests SUT

Write
the simplest
code to pass
the test
KISS - Keep It Simple, Stupid
!
- (void)increment
{
!
}
!
@end
2.
Tests SUT

Write
the simplest
code to pass
the test
!
- (void)increment
{
!
_count = 2;
}
!
@end
2.
Tests SUT

Write
the simplest
code to pass
the test
!
- (void)increment
{
!
}
!
@end With this simple line of code,
we are making the test pass.
_count = 2;
2.
Tests SUT

Now, you may complain “This implementation is really
stupid…”
And, it is!!! …It has to be! !
This is because it satisfies in the cleanest way all the tests
we have so far.

Wouldn’t it be better if we made the method
contain something like “_count ++;”
instead?!
!
So that we’d be making sure it’ll pass some
future tests we’d have to implement?

Come on, why not???
!
Explain yourself!

“We want to live in the present. Not in the future.”
!
Because the present will guide us in ways we might
not expect.
And that IS GOOD!

4 questions that will help you
create the simplest thing that could possibly work

The situation:
• You had a failing test.
• You went to production code and made the test
pass in the simplest way you thought possible.
• But… Was it really the simplest way?

The answer:
• We need to define what we consider being simple.
• For that, we’ll look at the code we’ve written and
ask ourselves the following…

Can I implement the same solution in a way that is…

• …more hardcoded…

• …closer to the beginning of the method I wrote it in…

• …less indented (in as “less” scopes as possible,
like if’s, loops, try-catch, etc)…

• …shorter (literally less characters to write) yet still
readable…

• …shorter (literally less characters to write) yet still
readable…
…AND STILL MAKE ALL THE TESTS PASS?

Example
!
- (void)increment
{
!
}
!
@end
Tests
test 1 incr = 2

Example
!
- (void)increment
{
!
}
!
@end
Tests
test 1 incr = 2
_count = 2;

Example
!
- (void)increment
{
!
}
!
@end
Tests
test 1 incr = 2
test 2 incr = 3
_count = 2;

test 1 incr = 2
test 2 incr = 3
Example Tests
!
- (void)increment
{
!
_count ++;
}
!
@end

test 1 incr = 2
test 2 incr = 3
Example Tests
_count ++;
if (_count == 1)
{
_count = 2;
}
else if (_count == 2)
{
_count = 3;
}
!
- (void)increment
{
!
}
!
@end

test 1 incr = 2
test 2 incr = 3
Example Tests
!
- (void)increment
{
!
_count ++;
}
!
@end
if (_count == 1)
{
_count = 2;
}
else if (_count == 2)
{
_count = 3;
Simpler than }

Refactor!
to make code
clean
Both testing and production code.
3.

Refactor!
to make code
clean
We have nothing to refactor so far because our code
remains clean…
3.

Refactor!
to make code
clean
We have nothing to refactor so far because our code
remains clean…
So, we can skip this step.
3.

Don’t refactor when you have failing tests.

Always start refactoring from a clean state.

Make sure all your tests keep passing after refactoring.

The pillars of good tests
Every test you write must be:
1. Trustworthy
2. Maintainable
3. Readable

Tips to have trustworthy tests
★ Decide when to remove or change tests.
★ Avoid test logic.
★ Test only one thing.
★ Make tests easy to run.
★ Assure code coverage.

Ya Ain’t Gonna Need It
The "YAGNI" principle

If you write tests that describe what's needed of your app
code, and you only write code that passes those tests,
you will never write any code you don’t need.
This encourages production code to be simple, and
avoids wasting time writing code that won’t have any
effect later.
A test-driven app should have no unused code, and no
(or very little) untested code.

Remember: If you find yourself thinking during the
refactoring stage that there are some changes you could
make to have the code support more conditions, stop.
!
Why aren’t those conditions tested for in the test cases?
Because those conditions don’t arise in the app.
!
So, don’t waste time adding the support, because…
!
!

Remember: If you find yourself thinking during the
refactoring stage that there are some changes you could
make to have the code support more conditions, stop.
!
Why aren’t those conditions tested for in the test cases?
Because those conditions don’t arise in the app.
!
So, don’t waste time adding the support, because…
!
!
YA AIN’T
GONNA
NEED IT

Should we test private methods?

Should we test
private methods…?
To answer that, let's observe the following fact:
!
You have already tested your private methods.

By following the TDD's red-green-refactor approach, you
designed your objects’ public APIs to do the work those
objects need to do.
!
With that work specified by the tests, you are free to organize
the internal plumbing of your classes as you see fit.

Your private methods have already been tested because all
you are doing is refactoring behavior that you already have
tests for.

You should never end up in a situation where a private
method is untested or incompletely tested, because you
create them only when you see an opportunity to clean up
the implementation of public methods.

This ensures that the private methods exist only to support
the classes’ public behavior, and that they must be invoked
during testing because they are definitely being called
from public methods.

TDD benefits
✓ A 2005 study found that using TDD meant writing more
tests and, in turn, developers who wrote more tests
tended to be more productive.
✓ Programmers using pure TDD reported they only rarely
felt the need to invoke a debugger.
✓ TDD offers more than just simple validation of
correctness, but can also drive the design of a program.
✓ TDD gives the development team, and subsequent users,
a greater level of confidence in the code.

TDD benefits
✓ Despite the fact that more code is required with TDD
because of the testing code, the total code
implementation time could be shorter.
✓ TDD can lead to more modularized, flexible and
extensible code.
✓ TDD suggests a better modularization, easier reuse and
testing of the developed software products.
✓ TDD raises the overall code quality in the projects, which
saves time due to a better maintainability and an easier
bug-fixing process.

Some TDD goals
๏ Increase the amount of test code coverage.
๏ Increase the amount of test code coverage relative to the
amount of code churn.
๏ Reduce the amount of bug reopening.
๏ Reduce the average bug-fixing time (the time from "bug
opened" to "bug closed").

TDD shortcomings
TDD does not perform sufficient testing in situations where
full functional tests are required to determine success or
failure due to extensive use of unit tests.
If the developer misinterprets the requirements
specification for the module being developed, both the
tests and the code will be wrong, as giving a false sense
of correctness.
A high number of passing unit tests may bring a false
sense of security, result in in fewer additional software
testing activities, such as integration testing and
compliance testing.

TDD shortcomings
Overtesting can consume time both to write the excessive
tests, and later, to rewrite the tests when requirements
change.
Hard learning curve. Very difficult at the beginning due to
drastic changes which are involved in the process.

Real case of a Pilot Project
Team progress and output measured with and without tests
That’s why it’s important to emphasize that, although unit testing can increase the
amount of time it takes to implement a feature, the time balances out over the product’s
release cycle because of increased quality and maintainability.
source: The Art Of Unit Testing - Roy Osherove

Is TDD worth it?
(taken from Jon Reid’s blog “Quality Coding”)

- (id)calculateSomethingFromArg:(id)arg;
message
return value
SUT

- (id)calculateSomethingFromArg:(id)arg;
message
return value
SUT
Return Value Verification

- (void)doSomething;
SUT
initial state

SUT
initial state
message

SUT
initial state
message
state accessor
result state

SUT
State Verification
initial state
message
state accessor
result state

State-based testing (also called state verification) determines whether the exercised
method worked correctly by examining the SUT after the method is exercised.
SUT
State Verification
initial state
message
state accessor
result state

message Dependent
SUT
object

Interaction Verification
message Fake
SUT
object
(a.k.a. Behavior Verification)

Interaction Verification
message Fake
SUT
object
(a.k.a. Behavior Verification)
Interaction testing is testing how an object sends input to or receives input
from other objects—how that object interacts with other objects.

Working with external
dependencies

What is an external dependency?
Real
SUT Object
Class Collaborator
?
request something
expect a value back
HOW?
We shouldn’t care
External
dependency
An external dependency is an object in your system
that your code under test interacts with, and over
which you have no control.

External dependencies
• Filesystems
• Managers
• Handlers
• Connections
• Formatters
• Etc
How are we going to deal with an
external dependency
when we need to test our SUT?
We need to make sure our external
dependency works as we expect, since
we are NOT testing it, but our SUT.
FAKE OBJECTS

Fake Objects
A fake object is just an object that mimics the behavior of a
real object in controlled ways.
!
We define how we want the fake object to respond to certain
stimulations, such as method calls.
Real
SUT Object
Class Collaborator
?
request something
expect a value back
HOW?
We shouldn’t care
External
dependency

Fake Objects
A fake object is just an object that mimics the behavior of a
real object in controlled ways.
!
We define how we want the fake object to respond to certain
stimulations, such as method calls.
request something
Fake
Object SUT
expect a value back
Class Collaborator
We tell it what to
respond
In such a fast,
controllable and
kind of hardcoded
way.

Fake Objects
request something
Fake
Object SUT
expect a value back
Class Collaborator
We tell it what to
respond…
Test
Class … and then we assert the result.
(AGAINST WHOM…?)

Fake Objects
communication
SUT STUB
Test
Class
assert
against
SUT

Fake Objects
communication
SUT MOCK
Test
Class
assert
against
fake object

Fake Objects
If we assert against…
the system under test the object is just a stub.
S F
T
the fake object the object is a mock.
S F
T

Fake Objects
S F
T
S F
T
We can have as many stubs as we need
F
F
F

Fake Objects
S F
T
We can have at most one mock per test
S F
T
F
F
F
F

Fake Objects
S F
We can have at most one mock per test
S F
T
F
F
F
F
T
We should never assert against two different things within the same test!

Fake Objects
However, we could end up having a configuration like
this one…
SUT Fake
Test
Fake
Fake
Fake

Fake Objects
However, we could end up having a configuration like
this one…
SUT Mock
Test
Stub
Stub
Stub
Where we have multiple stubs, but only one mock.

Fake Objects
How do we build fake objects?
Manually
By using a framework
• OCMock
• OCMockito
• Etc

How do we make external dependencies interact
with our SUT?
Dependency Injection
C’mon…
It ain’t gonna hurt!
THE DEPENDOCTOR

✤ Dependency Injection
✤ Design for Testing
Both are important topics on TDD that won’t be explained in
this talk because they are too much extensive that they’d
require another complete talk to be minimally understood.

Objective-C Unit Testing Frameworks
❖ OCUnit!
❖ XCTest (Xcode 5 onwards)

❖ OCUnit!
Integrates with OS X Server
CI using Bots

❖ OCUnit!
OCHamcrest
OCMockito
Integrates with OS X Server
CI using Bots

UI tests
@property (strong, nonatomic)
IBOutlet UIButton *button;

UI tests
- (IBAction)buttonPressed:(id)sender;

UI tests
Test 1: Is outlet hooked up?

UI tests
Test 2: Is outlet connected to action?

UI tests
Test 2: Is outlet connected to action?
Test 3: Invoke action directly.

Test-Driven iOS
Development
by Graham Lee
It’s like the holy bible…
…for iOS TDD developers
2012 Objective-C

The Art Of Unit Testing
with Examples in .NET
by Roy Osherove
2009 .NET

xUnit Test Patterns
Refactoring Test Code
by Gerard Meszaros
2007 Java

Working Effectively With
Legacy Code
by Michael Feathers
2005 Java, C++, C

Jon Reid’s blog
http://qualitycoding.org/
2011 - Actuality

couldn’t be missing…
Wikipedia
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/Mock_object

Other websites and articles
http://www.jayway.com/2010/01/15/test-driven-development-in-xcode/
!
http://www.sunetos.com/items/2011/10/24/tdd-ios-part-1/
!
https://www.youtube.com/watch?v=S5MvykD3yiE
(iOS Unit Testing Like A Boss by Matt Darnal)
!
http://www.mockobjects.com/
!
http://osherove.com/blog/2010/1/6/tdd-4-questions-that-will-help-you-
create-the-simplest-thing.html
!
http://martinfowler.com/articles/mocksArentStubs.html

That’s all, folks!
(for now…)

I hope you start liking
TDD :)
Pablo Villar - April 2014 @ InakaLabs

iOS Test-Driven Development

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to iOS Test-Driven Development (20)

Recently uploaded (20)

iOS Test-Driven Development