tdd,bdd and unit testing in ruby @[email protected]
TRANSCRIPT
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?