Propulsez votre architecture grâce au TDD et aux mocks (Agile Québec 2013)
-
Upload
elapse-technologies -
Category
Technology
-
view
826 -
download
4
description
Transcript of Propulsez votre architecture grâce au TDD et aux mocks (Agile Québec 2013)
© 2
01
2 Elap
se Techn
olo
gies
© 2013 Elapse Technologies© 2013 Elapse Technologies
Propulsez votre architecture grâce au
TDD et aux mocks
Agile Québec
12 juin 2013
nas
a.go
v
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Avertissement
Cette présentation est de niveau « avancé »
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Félix-Antoine Bourbonnais
Formateur & Coach Agile
o Tests automatisés: TDD, ATDD, BDD
o Orientation objet avancée
o Architecture agile
o Réusinage et qualité (Clean Code)
o Agile et Scrum
Concepteur de logiciels
o Pratiques de développement
o Java, Python, etc.
@fbourbonnais
linkedin.com/in/fbourbonnais/fr
elapsetech.com/fab
www.elapsetech.com
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Réchauffement…
Qui fait du TDD?
Qui utilise des Mocks?
Quelles sont vos attentes?
Images de: Idea Go / freedigitalphotos.net
Rameshng / Flickr.com
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Comment découvrir l’architecture?
TDD
Mocks
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
DOUBLURES ET MOCKSRappel sur les
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Rappel: les tests unitairesBut: tester les modules en isolation.
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Rappel: les mocks
CUTTest
CUT
A
B
X
N
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Rappel: les mocks
CTest
C
A
B
X
N
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Rappel: les mocks
CTest
C
A’
B’
A’’
LanceIOException
Retourne[1]
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
TDDRappels des fondements du
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Technique ou discipline?
Le TDD est une discipline
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Cycle du TDD
Écrire un test qui échoue
Faire passer le
testRé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
3
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
TDD « CLASSIQUE »Le design et le
Image: posterize / FreeDigitalPhotos.net
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
TDD classique
Image: nuchylee / FreeDigitalPhotos.net
Centré sur l’état et le résultat final
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
TDD classiqueExtraction des types
ClasseP Classe
R1
PTest
Division
R1Test
ClasseP
PTest
MockR1
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Le TDD classique
TDD Classique
Évolution du « design »
•Par division
•Extraction
Problèmes algorithmiques
•Traitement de données
•Calculs
Valide l’état
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
L’ORIENTATION OBJETRappel de
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
InfrastructureDomaineUI
Messages et collaboration
ClasseACtrl
Collaboration des objets fonctionnalité
ClasseB
ClasseC
IfaceE
ClassePersist
ClasseD
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Le « Tell don’t Ask »
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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 »
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Stim
ulu
sUn 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
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
PILOTER SON DESIGN AVEC DES MOCKS?
Comment
Image: jscreationzs / FreeDigitalPhotos.net
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Le TDD « Mockiste »
Centré sur les interactions et comportementsentre les objets considérant leur rôle
Images: sheelamohan / freedigitalphotos.net
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Le TDD « Mockiste »
Utilise les Mocks comme pierre angulaire
Images: cooldesign/ freedigitalphotos.net
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Évolution du « design »
Par le raffinement
Découverte des types par les Mocks
Définition de l’interface à partir des besoins établis dans les autres tests grâce aux mocks.
TDD « Mockiste »
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
TDD piloté par les MocksIdentifier les rôles requis (dépendances) par le module testé
Viewer<<Interface>>
LoaderViewer
Test
Découverte pas à pas
ClassePNGLoader
PNGLoaderTest
<<Interface>>
FileReader
MockMock
?
?
Tirer les types à partir de la demande
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
TDD piloté par les MocksArriver à destination…
Testacceptation
Viewer
UTest
Terminé
<<Interface>>
Loader
ClassePNGLoader
Utest
<<Interface>>
FileReader
FakeFileReader
Utest
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
En résumé
Quels effets aura ce comportement sur l’environnement immédiat?
De quoi est-ce que l’objet a besoin pour réaliser son travail en terme de
rôles ?
Quelle est la responsabilité de l’objet testé ?
Classe testée(CUT)
A
Besoin de(rôle)
B
Effet sur
Responsabilité
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Exemple
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(montant)
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
DÉMONSTRATIONPrésentation de la
Image: Stuart Miles / freedigitalphotos.net
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Soumissions à une conférence
#1 Soumission d’une présentation
En tant que soumissionnaireJe veux soumettre une présentation à une conférenceAfin 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
Démonstration
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Approche « outside-in »
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
Duplication?
Réusinage
TDD
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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 »
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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
Meilleur respect des
principes OO
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Désavantages de l’approche mockiste
Couplage du test avec la signature
des collaborateurs
Fonctionne mal avec des
problèmes algorithmiques
Génère beaucoup de mocks et d’interfaces
Danger: Trop focaliser sur le UI
(outside-in)
Tests unitaires =>
aucun test intégré de bas niveau.
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
La Bonne question…
Que voulez-vous maximiser ?
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Mauvaises odeurs détectables
Mauvaise odeurs avec les mocks
Beaucoup de Mocks
Couplage…
Difficile de les injecter
OCP ?Patron
« Factory »?
Beaucoup de
paramètres
Extraction d’un
concept?
…
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Rappel: TDD et architecture
+ Code testable
Rétroaction:« design »
simple?
-Code couplé
+ Code réutilisable
+ Architecture émergeante
Toutes approches
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Le mot de la fin…Questions? Poursuivre la discussion?
Image de digitalart / FreeDigitalPhotos.net
@fbourbonnais
Félix-Antoine Bourbonnais
elapsetech.com/fab
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Téléchargement
Image de anamkkml/ FreeDigitalPhotos.net et github.com
Diapositiveshttp://developpementagile.com/
architecture-mocks-tdd
Code sourcehttps://github.com/fbourbonnais/
propulsez-architecture-tdd-mocks
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Elapse Technologies
Formation
Accompagnement (coaching)
Conseils et diagnostiques
Votre allié en développement logiciel Agile
Agilité (Scrum, Lean, XP)
Qualité et tests automatisés
Architecture Agile
Pratiques de développement
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
Références
© 2
01
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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 2007http://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
3 Elap
se Te
chn
olo
gies
© 2
01
3 Elap
se Te
chn
olo
gies
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 2009http://www.infoq.com/interviews/feathers-freeman-design
Discussion – « Classic TDD or « London School » - anyopinions/comments/elaboration on Jason Gorman’s post? » GOOS Mailinglist, 2011. https://groups.google.com/d/topic/growing-object-oriented-software/dOmOIafFDcI/discussion