Nous savons depuis longtemps que les tests automatisés jouent un rôle important pour les équipes de développement Agile. Les grands ténors du TDD ont depuis longtemps identifié des gains en rapport avec le design (conception architecturale). Bien qu’il soit rare que l’on aborde et explique la façon d’obtenir ce bénéfice, la communauté a découvert avec le temps certaines pratiques et techniques permettant de maximiser l’émergence du design via le TDD. Cette présentation explique comment tirer le maximum de vos tests unitaires et des « mocks ». Nous présenterons, plus particulièrement, le style de TDD « mockiste » ou parfois appelée « école de Londres ». Ainsi, nous verrons comment les mocks peuvent nous aider à concevoir une architecture ayant une meilleure conception orientée objet. On y présentera également certaines astuces servant à faire ressortir l’essentiel de ses propres tests. La séance prendra la forme d’un tutoriel (démonstration) en réalisant pas à pas un design simple parsemé de trucs et astuces.

1. Propulsez votre architecture
grâce au TDD et aux Mocks
FÉLIX-ANTOINE BOURBONNAIS
ING.JR, PSM, M.SC.
Agile Montréal
12 mars 2014
nasa.gov

2. ©2014ElapseTechnologies
Image de Eyesplash
http://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benvenuto.jpg

3. Félix-Antoine Bourbonnais
Ing. jr, PSM, M.Sc.
www.elapsetech.com
Formation – Accompagnement – Conseils
fbourbonnais@elapsetech.com
elapsetech.com/fab
@fbourbonnais
linkedin.com/in/fbourbonnais
Contact
Formateur et Coach Agile
Tests automatisés
TDD
BDD et ATDD
Code propre
Qualité logicielle
Architecture Agile
Orientation objet
Orientation aspect
Design testable et émergeant
Scrum
Accompagnement d’équipes
Agent de changement

4. ©2014ElapseTechnologies
Avertissement
Cette présentation s’adresse
principalement à un public ayant déjà
expérimenté le TDD mais aucune
supervision n’est nécessaire pour en
profiter…

5. ©2014ElapseTechnologies
Réchauffement…
Qui fait du TDD?
Qui utilise des Mocks?
Quelles sont vos
attentes?
Images de Idea Go / freedigitalphotos.net et ameshng / Flickr.com

6. ©2014ElapseTechnologies
DOUBLURES ET MOCKS
Rappel sur les

7. ©2014ElapseTechnologies
Rappel: les tests unitaires

8. ©2014ElapseTechnologies
Rappel: les Mocks
CUT
Test
CUT
A
B
X
N

9. ©2014ElapseTechnologies
Rappel: les mocks
C
Test
C
A
B
X
N

10. ©2014ElapseTechnologies
Rappel: les mocks
C
Test
C
A’
B’
A’’
Lance
IOException
Retourne
[1]

11. ©2014ElapseTechnologies
TDD
Rappels des fondements du

12. ©2014ElapseTechnologies
Technique ou discipline?
Le TDD est une discipline

13. ©2014ElapseTechnologies
Rappel: Le cycle du TDD
Écrire un
test qui
échoue
Faire
passer le
test
Réusiner
On passe à la phase
« VERTE » dès qu’on a un
test qui échoue.
Erreur de compilateur
= « échec ».1
On passe à la phase « Réusinage »
dès que le test passe.
2
1

14. ©2014ElapseTechnologies
Shu-Ha-Ri
L’élève suit
l’enseignement
d’un maître
SHU
Il apprend
de d’autres
maîtres
(écoles)
HA
Il suit et a
sa propre
pratique…
RI
Power de Jardson Araújo du The Noun Project
Keikogi de Tiago Dos Reis Rodrigues duThe Noun Project

15. ©2014ElapseTechnologies
TDD « CLASSIQUE »
Le design et le
Image: posterize / FreeDigitalPhotos.net

16. ©2014ElapseTechnologies
TDD classique
Centré sur l’état
et le résultat final
Image: nuchylee / FreeDigitalPhotos.net

17. ©2014ElapseTechnologies
TDD classique
Extraction des types
Classe
P Classe
R1
PTest
Division
R1Test
Classe
P
PTest
Mock
R1

18. ©2014ElapseTechnologies
TDD classique
En résumé
TDD
Classique
Évolution du
« design »
•Par division
•Extraction
Problèmes
algorithmiques
•Traitement de
données
•Calculs
Valide l’état

19. ©2014ElapseTechnologies
L’ORIENTATION OBJET
Rappel de

20. ©2014ElapseTechnologies
InfrastructureDomaineUI
Messages et collaboration
Classe
ACtrl
Collaboration des objets  fonctionnalité
Classe
B
Classe
C
Iface
E
Classe
Persist
Classe
D

21. ©2014ElapseTechnologies
Le « Tell don’t Ask »
getAmi(joe)
.getCorps()
.getJambe(Orient.GAUCHE)
.setPosition(
sol + 5,
centre + 20)
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
Hein !?!

22. ©2014ElapseTechnologies
Pourquoi le « Tell don’t ask »
Cacher le
« comment »
Limiter l’effet
des
modifications
Limiter l’effet
d’avalanche
Réduire la
duplication
Laisser les objets
« s’occuper de
leurs oignons »
Éviter les
« domaines
anémiques »

23. ©2014ElapseTechnologies
Stimulus
Un objet est une boîte noire
Classe
Réception d’un message
Envoi d’un message à
un collaborateur
Envoi d’un message à
un collaborateur
Retour d’une réponse
Effet
Effet
…

24. ©2014ElapseTechnologies
PILOTER SON DESIGN AVEC DES MOCKS?
Comment
Image: jscreationzs / FreeDigitalPhotos.net

25. ©2014ElapseTechnologies
Le TDD « Mockiste »
Centré sur les interactions et comportements
entre les objets considérant leur rôle

26. ©2014ElapseTechnologies
Le TDD « Mockiste »
Utilise les Mocks comme pierre angulaire
Images: cooldesign/ freedigitalphotos.net

27. ©2014ElapseTechnologies
TDD « Mockiste »
Extraction des types
Découverte des types par les Mocks
Définition de l’interface à partir des besoins établis dans les autres tests

28. ©2014ElapseTechnologies
TDD piloté par les Mocks
Identifier les rôles
Viewer
<<Interface>>
Loader
Viewer
Test
Découverte pas à pas
Classe
PNGLoader
PNGLoader
Test
<<Interface>>
FileReader
Mock
Mock
?
?
Tirer les types à partir de la demande

29. ©2014ElapseTechnologies
TDD piloté par les Mocks
Arriver à destination…
Test
acceptation
Viewer
UTest
Terminé
<<Interface>>
Loader
Classe
PNGLoader
Utest
<<Interface>>
FileReader
Fake
FileReader
Utest

30. ©2014ElapseTechnologies
En résumé
Quelle est la responsabilité de
l’objet testé ?
De quoi est-ce que l’objet a besoin
pour réaliser son travail en terme de
rôles ?
Quels effets externes aura ce
comportement sur l’environnement
immédiat?
Classe testée
(CUT)
Responsabilité
A
Besoin de A
(rôle)
B
Effet sur B

31. ©2014ElapseTechnologies
Exemple
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(montant)

32. ©2014ElapseTechnologies
DÉMONSTRATION
Présentation de la
Image: Stuart Miles / freedigitalphotos.net

33. ©2014ElapseTechnologies
Démonstration
Soumissions à une conférence
#1 Soumission d’une présentation
En tant que soumissionnaire
Je veux soumettre une présentation à une conférence
Afin qu’elle soit évaluée par le comité de sélection
Critères d’acceptation
• Il est possible de soumettre une présentation
• La présentation est accumulée en attendant d’être évaluée par le comité
• Le comité est avisé qu’une nouvelle présentation doit être évaluée

34. ©2014ElapseTechnologies
CONCLUSION et RÉSUMÉ

35. ©2014ElapseTechnologies
Approche « outside-in »
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
Duplication?
Réusinage
TDD

36. ©2014ElapseTechnologies
Piloter le design par les mocks
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
MyLibraryView
…Presenter
OnlineLibrary Book
LibraryProvider
LibraryRealTime
View
…Presenter
OnlineService
Moc
k
Moc
k
Composer à partir
des interactions
Position « utilisateur »
Explorations successives
(étape par étape)
Reporter les décisions
d’implémentations
Explorer sans trop
se compromettre

37. ©2014ElapseTechnologies
Avantages de l’approche mockiste
Favorise le
« Tell don’t ask »
Moins de
« trains d’appels »
(Demeter)
Retarde les décisions
d’implémentations
Favorise un design
testable
Requiert moins
d’objets
implémentés pour
avoir une rétroaction
Classe fautive ciblée
en cas d’échec

38. ©2014ElapseTechnologies
Avantages de l’approche mockiste
Développement piloté
par les besoins
(need-driven)
Définir les interfaces à
partir des appelants
Focalise sur le « Quoi »
avant le « Comment »

39. ©2014ElapseTechnologies
Ce que l’on obtient généralement
Hiérarchie mince
Design basé sur
les rôles
Abstraction
(rôles)
Nommage clair
pour l’appelant
Possible meilleur
respect des
principes OO

40. ©2014ElapseTechnologies
Désavantages de l’approche mockiste
Couplage du test
avec la signature
des collaborateurs
Fragiliser les tests
Fonctionne mal
avec des
problèmes
algorithmiques
Peut générer
beaucoup de
Mocks et
d’interfaces
Manquer de tests
intégrés
(pyramide)

41. ©2014ElapseTechnologies
La bonne question…
Que voulez-vous
maximiser ?

42. ©2014ElapseTechnologies
Complémentarité
Cette école 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

43. ©2014ElapseTechnologies
Rappel: TDD et architecture
+
Code testable
+ de
« design »
simple?
- de code
couplé
+ de code
réutilisable
+
d’architecture
émergeante

44. ©2014ElapseTechnologies
Pour aller plus loin…
Image de anamkkml/ FreeDigitalPhotos.net et github.com
Code source
https://github.com/fbourbonn
ais/propulsez-architecture-tdd-
mocks
Diapositives
http://developpementagile.com/ar
chitecture-mocks-tdd
Les tests en
agilités
TDD pour
gestionnaires
Introduction à
l’ATDD et BDD
TDD avancé
TDD
Concepts
OO avancés
Nos formations sur le sujet
www.elapsetech.com/formation

45. ©2014ElapseTechnologies
Merci Mon nom
Félix-Antoine Bourbonnais
Notre blogue
developpementagile.com
Notre site
elapsetech.com
Mon Twitter
@fbourbonnais
Mon LinkedIn
linkedin.com/in/fbourbonnais/fr

46. ©2014ElapseTechnologies
Elapse Technologies
Formation
Accompagnement (coaching)
Mentorat virtuel
Conseils et diagnostics
Agilité (Scrum, Lean, XP)
Qualité et tests automatisés
Architecture Agile
Pratiques de développement
Votre allié en développement logiciel Agile

47. ©2014ElapseTechnologies
Références

48. ©2014ElapseTechnologies
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
http://www.infoq.com/presentations/Mock-Objects-Nat-Pryce-Steve-
Freeman
Martin Fowler, Mocks Aren’t Stubs, 2 janvier 2007.
[Résumé des approches]
http://martinfowler.com/articles/mocksArentStubs.html

49. ©2014ElapseTechnologies
Références
Steve Freeman, Sustainable Test-Driven Development. QCon San Francisco
2009.
http://www.infoq.com/presentations/Sustainable-Test-Driven-Development
Codemanship presents... Classic TDD vs. London School, 2011. [Critiqué]
http://www.youtube.com/watch?v=AUE155LISV4
Michael Feathers et Steve Freeman. Michael Feathers and Steve Freeman on
Design, InfoQ at QCon San Francisco 2009
http://www.infoq.com/interviews/feathers-freeman-design
Discussion – « Classic TDD or « London School » - any
opinions/comments/elaboration on Jason Gorman’s post? » GOOS Mailinglist,
2011.
https://groups.google.com/d/topic/growing-object-oriented-
software/dOmOIafFDcI/discussion