Présentation de Félix-Antoine Bourbonnais expliquant comment les mocks peuvent piloter votre design.

1. Propulsez
votre
architecture
grâce
aux
mocks
Confoo
2012
Montréal,
Québec,
Canada
2
mars
2012

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

4. Comment
découvrir
l’architecture?
Mocks
TDD

5. J’uKlise
déjà
des
mocks!
On
va
parler
des
mocks
pour
piloter
la
découverte
du
design!
Image: graur codrin / FreeDigitalPhotos.net

6. IntroducKon
aux
TESTS

7. Plusieurs
types
de
tests
IntégraKon
Bout-­‐en-­‐
AcceptaKon
bout
Système
Unitaire
…
Images: Renjith Krishnan, Salvatore Vuono, Jscreationzs, Photostock, Posterize
/ FreeDigitalPhotos.net

8. Tests
unitaires
But:
tester
les
modules
en
isola*on.

9. IntroducKon
aux
DOUBLURES
ET
MOCKS

10. onctionnement
tème FoncKonnement
10

11. tionnement
FoncKonnement
11

12. ionnement
FoncKonnement
12

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

14. IntroducKon
au
TDD

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

19. Rappel
de
L’ORIENTATION
OBJET

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é

31. ÉvoluKon
du
design
Réusinage
• InteracKons
• Signatures
• …

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

36. Approche
«
top-­‐down
»
UI
Réusinage
Domaine
Infrastructure
TDD
DuplicaKon?
Image: Simon Howden / FreeDigitalPhotos.net

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.

39. PrésentaKon
de
la
DÉMONSTRATION

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

42. Période
de
QUESTIONS
42

43. Références

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