TDD,BDD and Unit Testing in Ruby @RoyOsheroveroy@osherove.com

TDD,BDD and Unit

Testing in Ruby

@RoyOsher

ove

roy@osherove.com

A T

est

Dri

ven L

ife

Appro

ach

Expect Something big Expect many smaller

things as part of it

A T

est

Dri

ven L

ife

Appro

ach Acceptance Test

Fill in the gaps with Specs, Unit and Integration Testing

Engineering methodologies (waterfall for example..)

Agile (flexible & lightwheight) Methodologies eXtreme Programming

Test Driven Development

Team Agile - All rights

reserved

Putt

ing T

DD

in

Conte

xt

What is a

‘Unit’?

Unit

Of

Work

Production Code

Unit Of Work

Return Value/Exceptio

n

Noticeable State Change

3rd Party call

Public API

Test

Production Code

Unit Of Work

Return Value/Exceptio

n

Public API

Assert Test

Production Code

Unit Of Work

Noticeable State Change

Test

Public API

Ass

ert

Noti

ceable

Sys

tem

Behavi

or

Change

Noticeable by a user

of the public API, at the same level of

the entry point that made the change.

ACT and ASSERT on the same level of APIs.

Production Code

Unit Of Work

3rd Party call

Test

Public API

Asse

rt

3rd Party

Unit Of Work

Production Code

Unit Of Work

3rd Party call

Test

Public API

Asse

rt

3rd Party

Unit Of Work

Mock

Easier to find bugs

Easier to maintain

Easier to understand

Easier to Develop

Team Agile - All rights

reserved

Unit Testing makes your developer lives easier

Not structured

Not Repeatable

Not on all your code

Not easy to do as it should be

A framework is missing

Team Agile - All rights

reserved

All devs have already done Unit testing

Original was for SmallTalk Kent Beck and Erich Gamma

Ported to Various languages and platforms JUnit, CppUnit, DUnit, VBUnit, RUnit, PyUnit, Sunit,

HtmlUnit, …

Good list at www.xprogramming.com

Standard test architecture

Introducing RSpecTeam Agile - All rights

reserved

The xUnit Frameworks

Fram

ew

ork

s

Test-Unit Minitest RSpec

Acc

epta

nce

Fr

am

ew

ork

s

Cucumber Steak Turnip

Demo

Make it FailNo code without a failing test

Make it WorkAs simply as possible

Make it BetterRefactor

Team Agile - All rights

reserved

Test-Driven Development

Dem

o

String

Calculator

Osherove.com/kata

Demo String Calc

Simplicity

Team Agile - All rights

reserved

Sim

plic

ity

take

2 As many assumptions

as you can Then debunk them one by one

Exa

mple

The input will always

be empty - wrong, if I send in a

… The input will always

be one number if it is

not empty - wrong, if I send in …

Common

Questions

Think through the requirement Think about the design

and usability of the API

There’s never time to

write it afterwards You write much less tests (if at all) otherwise

Team Agile - All rights

reserved

Why

wri

te t

he t

est

befo

re t

he c

ode?

Make sure the test does not

have a bug Make sure you’re testing the

right thing Define a small problem to solve

When the test passes, you are

done

If you can’t write that test, you

may Not understand the requirement

Have over designed things (not

testable) Not have a small enough problem

to solve

Team Agile - All rights

reserved

Why

make

it f

ail

firs

t?

Force you to write more tests you hadn’t

considered Simpler solutions are

easier to maintain Better code coverage

of tested code

Team Agile - All rights

reserved

Why

solv

e it

as

sim

ply

as

poss

ible

?

Constantly improve the

design of the code Unit tests act as safety net

Remove duplication,

improve readability and

maintainability You’ll need to when things

change (requirements,

your understanding of

them, other factors..)Team Agile - All rights

reserved

Why

Refa

ctor?

60% of the features you

build won’t be used Hopping between tasks can

leave stuff undone Something working is better

than nothing Meanwhile requirements may

change, you lose less work

(simpler solution, less time).

Small units of work are easier

for people – better life!

Feeling of accomplishment

that stuff is doneTeam Agile - All rights

reserved

Why

work

in

crem

enta

lly?

It’s a much bigger problem

to solve Longer time to “green bar”

feeling You won’t know you have

good code coverage Solution probably more

complex than it could have

been To support all tests at once

Also takes longer to create,

more possibility of undetected bugsTeam Agile - All rights

reserved

Why

not

wri

te m

any

test

s at

once

?

Implement –

7d

Testing – 3d

Fix Bugs – 3d

Testing – 3d

Fix Bugs – 2d

Testing – 1d

Release(19d)

Implement –

14d

Testing – 3d

Fix Bugs – 2d

Testing – 1d

Fix Bugs – 1d

Testing – 1d

Release(22d)

Team Agile - All rights reserved

Sce

nario

Potential “Production

Bugs” reduced by up to

90% - > more stable

product Better designed interfaces API Documentation

Safety net for past and

future Happier customer Happier codersTeam Agile - All rights

reserved

RO

I

Implementat

– 7d

Integration –

7d

Testing – 3d

Fix Bugs – 3d

Testing – 3d

Fix Bugs – 2d

Testing – 1d

Release(26d)

Implement –

14d

Integration –

2d

Testing – 3d

Fix Bugs – 2d

Testing – 1d

Fix Bugs – 1d

Testing – 1d

Release(24d)

Team Agile - All rights reserved

Sce

nario

Questions?