© 2
01
2 Elap
se Techn
olo
gies
Propulsez votre architecture grâce au TDD et aux mocks
Agile Tour 2012 Québec, Canada
6 novembre 2012
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Félix-Antoine Bourbonnais Ing. jr, PSM-I
Formateur et Coach Agile
Spécialités
o Tests: TDD, ATDD, BDD, etc.
o Orientation objet avancée
o Réusinage et qualité (Clean Code)
o Agile Scrum
Développement
o Architecture logicielle agile
o Java, Python, etc.
2
@fbourbonnais
linkedin.com/in/fbourbonnais
http://bit.ly/Qut7Fm
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Réchauffement…
Quelles sont vos attentes?
Qui fait du TDD?
Qui utilise des Mocks?
3
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Comment découvrir l’architecture?
TDD
Mocks
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies DOUBLURES ET MOCKS
Introduction aux
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Tests unitaires But: tester les modules en isolation.
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Fonctionnement
7
CUTTest
CUT
A
B
X
N
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Fonctionnement
8
CUTTest
CUT
A
B
X
N
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Fonctionnement
9
CUTTest
CUT
A’
D’
A’’ A’’’
Retourne [1, 2, 3]
Lance IOException
Retourne [1]
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies TDD
Rappels des fondements du
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Cycle du TDD
Écrire un test qui échoue
Faire passer le
test Réusiner
11
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
3
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
TDD « CLASSIQUE » Le design et le
Image: posterize / FreeDigitalPhotos.net
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
TDD classique
Image: nuchylee / FreeDigitalPhotos.net
Centré sur l’état et le résultat final
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
TDD classique Extraction des types
Classe P Classe
R1
PTest
Division
R1Test
Classe P
PTest
Mock R1
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Le TDD classique
Centré sur la logique
Évolution du « design »
o Par division
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
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies L’ORIENTATION OBJET
Rappel de
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Infrastructure Domaine UI
Messages et collaboration
Classe A
Collaboration des objets fonctionnalité
Classe B
Classe C
Classe E
Classe F
Classe D
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Le « Tell don’t Ask »
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Stim
ulu
s 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
Effe
t
Effe
t
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
PILOTER SON DESIGN AVEC DES MOCKS?
Comment
Image: jscreationzs / FreeDigitalPhotos.net
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Le TDD « Mockiste »
Centré sur les
o Interactions entre les objets
o Rôles et responsabilités
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
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
TDD piloté par les Mocks Identifier les rôles requis (dépendances) par le module testé
Viewer <<Interface>>
Loader Viewer
Test
Découverte pas à pas
Classe PNGLoader
PNGLoaderTest
<<Interface>>
FileReader
Mock Mock
?
?
Tirer les types à partir de la demande
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
TDD piloté par les Mocks Arriver à destination…
Test acceptation
Viewer
UTest
Terminé
<<Interface>>
Loader
Classe PNGLoader
Utest
<<Interface>>
FileReader
Fake FileReader
Utest
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
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)
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies DÉMONSTRATION
Présentation de la
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Soumissions à une conférence
Système pour gérer les propositions soumises à une conférence
Story #1:
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
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Approche « top-down »
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
Duplication?
Réusinage
TDD
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Piloter le design par les mocks
Composer à partir des interactions
Position « utilisateur »
Explorations successives (étape par étape)
Reporter les décisions d’implémentations
Explorer sans trop se compromettre
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
MyLibraryView
…Presenter
OnlineLibrary Book
LibraryProvider
LibraryRealTimeView
…Presenter
OnlineService
Mock
Mock
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
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 »
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
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Ce que l’on obtient généralement
Hiérarchie mince
Design basé sur les rôles
Abstraction (sous la forme de rôles)
Nommage en position d’utilisateur
o Méthodes et types
Meilleur respect du « Tell don’t ask »
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Désavantages
Moins adapté pour découvrir les détails (le « comment »)
Peut résulter en une trop grande séparation
o Trop de classes/interfaces
Fonctionne moins bien sur les systèmes basés sur les données et fortement algorithmiques
32
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Complémentarité
Cette 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)
33
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
TDD et architecture
Favorise l’écriture de code testable
Offre une rétroaction concernant la facilité d’utilisation du « design »
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
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
QUESTIONS Période de
35
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Téléchargement
Image: rajcreationzs / FreeDigitalPhotos.ne 36
Téléchargez les diapositives complètes sur developpementagile.com
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
Références
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
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
© 2
01
2 Elap
se Techn
olo
gies ©
20
12
Elapse Tech
no
logies
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