Contenu connexe Similaire à Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012) (20) Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Québec 2012)2. Félix-Antoine Bourbonnais
Ing. jr, PSM-I
Formateur et Coach Agile
Spécialités
o Tests: TDD, ATDD, BDD, etc.
© 2012 Elapse Technologies
© 2012 Elapse Technologies
o Orientation objet avancée http://bit.ly/Qut7Fm
o Réusinage et qualité (Clean Code)
@fbourbonnais
o Agile Scrum
linkedin.com/in/fbourbonnais
Développement
o Architecture logicielle agile
o Java, Python, etc.
2
3. Réchauffement…
Quelles sont vos
attentes?
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Qui fait du TDD?
Qui utilise des Mocks?
3
4. © 2012 Elapse Technologies
© 2012 Elapse Technologies
Comment découvrir l’architecture?
TDD
Mocks
5. © 2012 Elapse Technologies
© 2012 Elapse Technologies
DOUBLURES ET MOCKS
Introduction aux
7. © 2012 Elapse Technologies
© 2012 Elapse Technologies
7
N
X
A
B
Fonctionnement
CUT
CUT
Test
8. © 2012 Elapse Technologies
© 2012 Elapse Technologies
8
N
X
A
B
Fonctionnement
CUT
CUT
Test
9. Fonctionnement
A’ A’’ A’’’
Retourne Lance Retourne
© 2012 Elapse Technologies
© 2012 Elapse Technologies
[1] IOException [1, 2, 3]
CUT
CUT
Test
D’
9
10. © 2012 Elapse Technologies
© 2012 Elapse Technologies
Rappels des fondements du
TDD
11. Cycle du TDD
Écrire un 1
On passe à la phase
test qui « VERTE » dès qu’on a un
échoue test qui échoue.
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Erreur de compilateur
= « échec ».
Faire
3 Réusiner passer le
test
2
On passe à la phase « Réusinage »
dès que le test passe.
11
12. © 2012 Elapse Technologies
© 2012 Elapse Technologies
Le design et le
TDD « CLASSIQUE »
Image: posterize / FreeDigitalPhotos.net
13. TDD classique
Centré sur l’état et le résultat final
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Image: nuchylee / FreeDigitalPhotos.net
14. TDD classique
Extraction des types
Classe Division
P Classe Classe
© 2012 Elapse Technologies
© 2012 Elapse Technologies
P R1
Mock
R1
PTest PTest R1Test
15. Le TDD classique
Centré sur la logique
Évolution du « design »
o Par division
© 2012 Elapse Technologies
© 2012 Elapse Technologies
o Découverte des types par extraction
Avantages – « Détails et logique»
o Construit des composants très modulaires et faiblement
couplés
o Facilite la réutilisation
15
16. © 2012 Elapse Technologies
© 2012 Elapse Technologies
L’ORIENTATION OBJET
Rappel de
17. Messages et collaboration
Classe
C
Classe
B
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Classe
Classe D
A
Classe Classe
E F
UI Domaine Infrastructure
Collaboration des objets fonctionnalité
18. Le « Tell don’t Ask »
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
19. Un objet est une boîte noire
Stimulus
Réception d’un message
Envoi d’un message à
© 2012 Elapse Technologies
© 2012 Elapse Technologies
un collaborateur
Effet
Classe
Envoi d’un message à
un collaborateur
Effet
Retour d’une réponse
20. © 2012 Elapse Technologies
© 2012 Elapse Technologies
Comment
PILOTER SON DESIGN AVEC DES
MOCKS?
Image: jscreationzs / FreeDigitalPhotos.net
21. Le TDD « Mockiste »
Centré sur les
o Interactions entre les objets
o Rôles et responsabilités
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Utilise les Mocks comme pierre angulaire
Évolution du « design »
o Par le raffinement
o Découverte des types par les Mocks
o Définition de l’interface à partir des besoins établis dans
les autres tests grâce aux mocks.
22
22. TDD piloté par les Mocks
Identifier les rôles requis (dépendances) par le module testé
Viewer <<Interface>> <<Interface>>
Test
Viewer ? Loader FileReader
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Mock
Mock
PNGLoader Classe
Test ?
PNGLoader
Découverte pas à pas
Tirer les types à partir de la demande
23. TDD piloté par les Mocks
Arriver à destination…
Test <<Interface>> <<Interface>>
acceptation
Viewer Loader FileReader
© 2012 Elapse Technologies
© 2012 Elapse Technologies
UTest
Utest
Classe Fake
Utest
PNGLoader FileReader
Terminé
24. 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?
© 2012 Elapse Technologies
© 2012 Elapse Technologies
3. Quels effets aura ce comportement sur l’environnement
immédiat?
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(montant)
25. © 2012 Elapse Technologies
© 2012 Elapse Technologies
DÉMONSTRATION
Présentation de la
26. Soumissions à une conférence
Système pour gérer les propositions soumises à une
conférence
Story #1:
© 2012 Elapse Technologies
© 2012 Elapse Technologies
o Permettre la soumission d’une présentation
o Les présentations doivent être accumulées en attendant
d’être évaluées par le comité
o Notifier le comité à la réception
27. Approche « top-down »
UI
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Réusinage
Domaine
Infrastructure TDD
Duplication?
Image: Simon Howden / FreeDigitalPhotos.net
28. Piloter le design par les mocks
MyLibraryView
LibraryRealTime Composer à partir des
View
interactions
…Presenter …Presenter
UI
Position « utilisateur »
Moc
© 2012 Elapse Technologies
© 2012 Elapse Technologies
k
OnlineLibrary Book Explorations successives
Moc
(étape par étape)
LibraryProvider k
Reporter les décisions
Domaine
d’implémentations
OnlineService
Explorer sans trop se
compromettre
Infrastructure
Image: Simon Howden / FreeDigitalPhotos.net
29. Avantages
Favorise le respect du « Tell don’t ask »
Permet de définir les interfaces à partir des besoins
o Force à se concentrer sur le « Quoi » avant le « Comment »
© 2012 Elapse Technologies
© 2012 Elapse Technologies
o On définit d’abord le « Quoi » à partir des tests des autres
Retarde les décisions d’implémentations
Favorise un design testable
L’isolation favorise le réusinage
30
30. Ce que l’on obtient généralement
Hiérarchie mince
Design basé sur les rôles
Abstraction (sous la forme de rôles)
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Nommage en position d’utilisateur
o Méthodes et types
Meilleur respect du « Tell don’t ask »
31. Désavantages
Moins adapté pour découvrir les détails
(le « comment »)
Peut résulter en une trop grande séparation
© 2012 Elapse Technologies
© 2012 Elapse Technologies
o Trop de classes/interfaces
Fonctionne moins bien sur les systèmes basés sur les
données et fortement algorithmiques
32
32. Complémentarité
Cette technique doit
être combinée!
Alterner entre les
© 2012 Elapse Technologies
© 2012 Elapse Technologies
techniques apporte
généralement de bons
résultats.
Choisir selon ce que
l’on veut découvrir
(design ou algorithme)
33
33. TDD et architecture
Favorise l’écriture de code testable
Offre une rétroaction concernant la facilité
d’utilisation du « design »
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Favorise l’écriture de code faiblement couplé
Favorise l’écriture de code réutilisable
Favorise l’évolution de l’architecture et la découverte
progressive
o Colle à la réalité et aux besoins présents
34. 35
© 2012 Elapse Technologies
© 2012 Elapse Technologies
QUESTIONS
Période de
35. Téléchargement
Téléchargez les diapositives complètes sur
developpementagile.com
© 2012 Elapse Technologies
© 2012 Elapse Technologies
Image: rajcreationzs / FreeDigitalPhotos.ne 36
36. © 2012 Elapse Technologies
© 2012 Elapse Technologies
Références
37. 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 .
© 2012 Elapse Technologies
© 2012 Elapse Technologies
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
38. Références
Steve Freeman, Sustainable Test-Driven Development. QCon San Francisco
2009.
http://www.infoq.com/presentations/Sustainable-Test-Driven-
Development
© 2012 Elapse Technologies
© 2012 Elapse Technologies
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