2. Félix-‐Antoine
Bourbonnais
Ing.
jr,
PSM-‐I
! Formateur
et
Coach
Agile
! Enseignement
et
formaKons
o TDD,
Réusinage,
OO
avancé,
AOP,
tests,
Scrum
! Recherches
o AOP,
agilité,
tests
et
mocks
! Développeur
@Uourbonnais
o Java
et
Python
(principalement)
2
3. Réchauffement…
Quelles
sont
vos
aXentes?
Qui
fait
du
TDD?
Qui
uKlise
des
Mocks?
3
13. UKlisaKons
Piloter
(simuler
un
cas)
• Simuler
un
cas
précis
dans
un
objet
uKlisé
par
l’objet
testé.
• Exemple:
Simuler
une
excepKon
lancée.
Vérifier
un
comportement
• Vérifier
que
l’objet
testé
a
eu
l’effet
désiré
sur
un
autre
objet.
• Exemple:
Vérifier
que
la
méthode
a
été
appelée
sur
un
autre
objet.
13
15. Cycle
du
TDD
Écrire
un
1
On
passe
à
la
phase
test
qui
«
VERTE
»
dès
qu’on
a
un
échoue
test
qui
échoue.
Erreur
de
compilateur
=
«
échec
».
Faire
1
Réusiner
passer
le
test
2
On
passe
à
la
phase
«
Réusinage
»
dès
que
le
test
passe.
15
16. Pourquoi
faire
du
TDD
La
peur
du
changement…
Peur
=
î
maintenabilité
Image:
David
CasKllo
Dominici
/
FreeDigitalPhotos.net
16
17. Focaliser
sur
le
«
QUOI
»
Se
placer
en
posiKon
d’uKlisateur
du
code
Se
concentrer
sur
le
«
QUOI
»
«
Instead
of
just
using
tesKng
to
verify
our
work
aker
it’s
done,
TDD
turns
tesKng
into
a
design
ac*vity.
[1]
»
«
We
use
the
tests
to
clarify
our
ideas
about
what
we
want
the
code
to
do.
[1]»
[1]
Steve
Freeman
et
Nat
Pryce.
Growing
Object-‐Oriented
So2ware,
Guided
by
Tests.
Addison-‐
Wesley
Professional,
1
ediKon,
Octobre
2009.
17
18. TDD
et
architecture
! Favorise
l’écriture
de
code
testable
! Offre
une
rétroacKon
concernant
la
facilité
d’uKlisaKon
du
«
design
»
! Favorise
l’écriture
de
code
faiblement
couplé
! Favorise
l’écriture
de
code
réuKlisable
! Favorise
l’évoluKon
de
l’architecture
et
la
découverte
progressive
o Colle
à
la
réalité
et
aux
besoins
présents
20. Messages
et
collaboraKon
Classe
C
Classe
B
Classe
Classe
D
A
Classe
Classe
E
F
UI
Domaine
Infrastructure
Collabora*on
des
objets
à
fonc*onnalité
21. Le
«
Tell
don’t
Ask
»
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
22. Pourquoi
le
«
Tell
don’t
ask
»
! Cacher
le
«
comment
»
! Limiter
l’effet
des
modificaKons
à
la
logique
(algorithme)
! Éviter
les
«
trains
»
d’appels
! Réduire
la
duplicaKon
! Laisser
les
objets
«
s’occuper
de
leurs
oignons
»
! Éviter
les
«
domaines
anémiques
»
23. Un
objet
est
une
boîte
noire
SKmulus
RécepKon
d’un
message
Envoi
d’un
message
à
un
collaborateur
Effet
Classe
Envoi
d’un
message
à
un
collaborateur
Effet
Retour
d’une
réponse
24. Le
design
et
le
TDD
«
CLASSIQUE
»
Image: posterize / FreeDigitalPhotos.net
25. TDD
classique
Centré
sur
l’état
et
le
résultat
final.
Image: nuchylee / FreeDigitalPhotos.net
26. TDD
classique
ExtracKon
des
types
Classe
Division
P
Classe
Classe
P
R1
Mock
R1
PTest
PTest
R1Test
27. Comment
PILOTER
SON
DESIGN
AVEC
DES
MOCKS?
Image: jscreationzs / FreeDigitalPhotos.net
28. TDD
piloté
par
les
Mocks
Tirer
à
parKr
des
besoins
B
Capacité
de
B
et
C
A
Besoins
de
A
(services)
C
Tirer
les
types
à
parKr
de
la
demande
29. TDD
piloté
par
les
Mocks
IdenKfier
les
rôles
requis
(dépendances)
par
le
module
testé
Viewer <<Interface>>
<<Interface>>
Test
Viewer
?
Loader
FileReader
Mock
Mock
PNGLoader Classe
Test
?
PNGLoader
Découverte
pas
à
pas
Tirer
les
types
à
parKr
de
la
demande
30. TDD
piloté
par
les
Mocks
Arriver
à
desKnaKon…
Test
<<Interface>>
<<Interface>>
acceptaKon
Viewer
Loader
FileReader
UTest
Utest
Classe
Fake
Utest
PNGLoader
FileReader
Terminé
32. En
résumé
1. Établir
quelle
est
la
responsabilité
de
l’objet
testé
2. De
quoi
est-‐ce
que
l’objet
a
besoin
pour
réaliser
son
travail
en
terme
de
rôles?
3. Quels
effets
aura
ce
comportement
sur
l’environnement
immédiat?
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(montant)
33. Avantages
! Favorise
le
respect
du
«
Tell
don’t
ask
»
! Permet
de
définir
les
interface
à
parKr
des
besoins
o Force
à
se
concentrer
sur
le
«
Quoi
»
avant
le
«
Comment
»
o On
définit
d’abord
le
«
Quoi
»
à
parKr
des
tests
des
autres
! Retarde
les
décisions
d’implémentaKons
! Favorise
un
design
testable
! L’isolaKon
favorise
le
réusinage
33
34. Ce
que
l’on
obKent
généralement
! Hiérarchie
mince
! Design
basé
sur
les
rôles
! AbstracKon
(sous
la
forme
de
rôles)
! Nommage
en
posiKon
d’uKlisateur
o Méthodes
et
types
! Meilleur
respect
du
«
Tell
don’t
ask
»
! Parfois
moins
de
temps
en
déverminage
pour
trouver
le
problème
lorsqu’un
test
ne
passe
plus
35. Désavantages
! Ne
permet
pas
d’établir
le
«
comment
»
! Peut
résulter
en
une
trop
grande
séparaKon
o Trop
de
classes/interfaces
! FoncKonne
moins
bien
sur
les
systèmes
basés
sur
les
données
35
37. Piloter
le
design
par
les
mocks
MyLibraryView
LibraryRealTime ! Composer
à
parKr
des
View
…Presenter
…Presenter
interacKons
UI
! PosiKon
«
uKlisateur
»
Mock
OnlineLibrary
Book
! ExploraKons
successives
(étape
par
étape)
Mock
LibraryProvider
! Reporter
les
décisions
Domaine
d’implémentaKons
OnlineService
! Explorer
sans
trop
se
compromeXre
Infrastructure
Image: Simon Howden / FreeDigitalPhotos.net
38. Favoriser
la
détecKon
des
mauvaises
odeurs...
! Beaucoup
de
Mocks
o Couplage…
! Difficile
d’injecter
les
Mocks
o Pourquoi
les
dépendances
ne
sont
pas
passées?
o Patron
«
Factory
»?
! Paramètres
mulKples
(constructeurs
et
méthodes)
o ExtracKon
d’un
concept?
! Incapable
de
trouver
un
nom
! Etc.
40. Complémentarité
! CeXe
technique
doit
être
combinée!
! Alterner
entre
les
techniques
apporte
généralement
de
bons
résultats.
! Choisir
selon
ce
que
l’on
veut
découvrir
(design
ou
algorithme)
40
41. Téléchargement
Évaluez
la
présentaKon
sur:
hXps://joind.in/6106
Téléchargez
les
diaposiKves
complètes
sur
developpementagile.com
Image: rajcreationzs / FreeDigitalPhotos.ne 41
44. Références
! Steve
Freeman,
Tim
Mackinnon,
Nat
Pryce,
et
Joe
Walnes.
Mock
roles,
Not
objects.
p.
236–246.
OOPSLA
’04.
Vancouver,
BC,
Canada,
ACM,
2004.
! Nat
Pryce,
et
Steve
Freeman,
InfoQ:
Mock
Roles
Not
Object
States
.
QCon
London
2007
hXp://www.infoq.com/presentaKons/Mock-‐Objects-‐Nat-‐Pryce-‐
Steve-‐Freeman
! MarKn
Fowler,
Mocks
Aren’t
Stubs,
2
janvier
2007.
[Résumé
des
approches]
hXp://marKnfowler.com/arKcles/mocksArentStubs.html
45. Références
! Steve
Freeman,
Sustainable
Test-‐Driven
Development.
QCon
San
Francisco
2009.
hXp://www.infoq.com/presentaKons/Sustainable-‐Test-‐Driven-‐
Development
! Codemanship
presents...
Classic
TDD
vs.
London
School,
2011.
[CriKqué]
hXp://www.youtube.com/watch?v=AUE155LISV4
! Michael
Feathers
et
Steve
Freeman.
Michael
Feathers
and
Steve
Freeman
on
Design,
InfoQ
at
QCon
San
Francisco
2009
hXp://www.infoq.com/interviews/feathers-‐freeman-‐design
! Discussion
–
«
Classic
TDD
or
«
London
School
»
-‐
any
opinions/comments/
elaboraPon
on
Jason
Gorman’s
post?
»
GOOS
Mailinglist,
2011.
hXps://groups.google.com/d/topic/growing-‐object-‐oriented-‐sokware/
dOmOIafFDcI/discussion