propulsez votre architecture grâce au tdd et aux mocks · propulsez votre architecture grâce au...
TRANSCRIPT
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
nas
a.go
v
© 2
01
4 Elap
se Techn
olo
gies
Image de Eyesplashhttp://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benvenuto.jpg
Félix-Antoine BourbonnaisIng. jr, PSM, M.Sc.
www.elapsetech.com
Formation – Accompagnement – Conseils
elapsetech.com/fab
@fbourbonnais
linkedin.com/in/fbourbonnais
Contact
Formateur et Coach Agile
Tests automatisés
TDDBDD et ATDD
Code propreQualité logicielle
Architecture AgileOrientation objet
Orientation aspect
Design testable et émergeant
ScrumAccompagnement d’équipesAgent de changement
© 2
01
4 Elap
se Techn
olo
gies
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…
© 2
01
4 Elap
se Techn
olo
gies
Réchauffement…
Qui fait du TDD?
Qui utilise des Mocks?
Quelles sont vos attentes?
Images de Idea Go / freedigitalphotos.net et ameshng / Flickr.com
© 2
01
4 Elap
se Techn
olo
gies
DOUBLURES ET MOCKS
Rappel sur les
© 2
01
4 Elap
se Techn
olo
gies
Rappel: les tests unitaires
© 2
01
4 Elap
se Techn
olo
gies
Rappel: les Mocks
CUTTest
CUT
A
B
X
N
© 2
01
4 Elap
se Techn
olo
gies
Rappel: les mocks
CTest
C
A
B
X
N
© 2
01
4 Elap
se Techn
olo
gies
Rappel: les mocks
CTest
C
A’
B’
A’’
LanceIOException
Retourne[1]
© 2
01
4 Elap
se Techn
olo
gies
TDD
Rappels des fondements du
© 2
01
4 Elap
se Techn
olo
gies
Technique ou discipline?
Le TDD est une discipline
© 2
01
4 Elap
se Techn
olo
gies
Rappel: Le 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
1
© 2
01
4 Elap
se Techn
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 ProjectKeikogi de Tiago Dos Reis Rodrigues duThe Noun Project
© 2
01
4 Elap
se Techn
olo
gies
TDD « CLASSIQUE »Le design et le
Image: posterize / FreeDigitalPhotos.net
© 2
01
4 Elap
se Techn
olo
gies
TDD classique
Centré sur l’étatet le résultat final
Image: nuchylee / FreeDigitalPhotos.net
© 2
01
4 Elap
se Techn
olo
gies
TDD classique
Extraction des types
ClasseP Classe
R1
PTest
Division
R1Test
ClasseP
PTest
MockR1
© 2
01
4 Elap
se Techn
olo
gies
TDD classique
En résumé
TDD Classique
Évolution du « design »
•Par division
•Extraction
Problèmes algorithmiques
•Traitement de données
•Calculs
Valide l’état
© 2
01
4 Elap
se Techn
olo
gies
L’ORIENTATION OBJET
Rappel de
© 2
01
4 Elap
se Techn
olo
gies
InfrastructureDomaineUI
Messages et collaboration
ClasseACtrl
Collaboration des objets fonctionnalité
ClasseB
ClasseC
IfaceE
ClassePersist
ClasseD
© 2
01
4 Elap
se Techn
olo
gies
Le « Tell don’t Ask »
getAmi(joe)
.getCorps()
.getJambe(Orient.GAUCHE)
.setPosition(
sol + 5,
centre + 20)
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
Hein !?!
© 2
01
4 Elap
se Techn
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
4 Elap
se Techn
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
4 Elap
se Techn
olo
gies
PILOTER SON DESIGN AVEC DES MOCKS?Comment
Image: jscreationzs / FreeDigitalPhotos.net
© 2
01
4 Elap
se Techn
olo
gies
Le TDD « Mockiste »
Centré sur les interactions et comportementsentre les objets considérant leur rôle
© 2
01
4 Elap
se Techn
olo
gies
Le TDD « Mockiste »
Utilise les Mocks comme pierre angulaire
Images: cooldesign/ freedigitalphotos.net
© 2
01
4 Elap
se Techn
olo
gies
TDD « Mockiste »
Extraction des types
Découverte des types par les MocksDéfinition de l’interface à partir des besoins établis dans les autres tests
© 2
01
4 Elap
se Techn
olo
gies
TDD piloté par les Mocks
Identifier les rôles
Viewer<<Interface>>
LoaderViewer
Test
Découverte pas à pas
ClassePNGLoader
PNGLoaderTest
<<Interface>>
FileReader
MockMock
?
?
Tirer les types à partir de la demande
© 2
01
4 Elap
se Techn
olo
gies
TDD piloté par les Mocks
Arriver à destination…
Testacceptation
Viewer
UTest
Terminé
<<Interface>>
Loader
ClassePNGLoader
Utest
<<Interface>>
FileReader
FakeFileReader
Utest
© 2
01
4 Elap
se Techn
olo
gies
En résumé
Quelle est la responsabilité de
l’objet testé ?
De quoi est-ce que l’objet a besoinpour 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
© 2
01
4 Elap
se Techn
olo
gies
Exemple
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(montant)
© 2
01
4 Elap
se Techn
olo
gies
DÉMONSTRATIONPrésentation de la
Image: Stuart Miles / freedigitalphotos.net
© 2
01
4 Elap
se Techn
olo
gies
Démonstration
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
© 2
01
4 Elap
se Techn
olo
gies
CONCLUSION et RÉSUMÉ
© 2
01
4 Elap
se Techn
olo
gies
Approche « outside-in »
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
Duplication?
Réusinage
TDD
© 2
01
4 Elap
se Techn
olo
gies
Piloter le design par les mocks
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
MyLibraryView
…Presenter
OnlineLibrary Book
LibraryProvider
LibraryRealTimeView
…Presenter
OnlineService
Mock
Mock
Composer à partir des interactions
Position « utilisateur »
Explorations successives(étape par étape)
Reporter les décisionsd’implémentations
Explorer sans trop se compromettre
© 2
01
4 Elap
se Techn
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
4 Elap
se Techn
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
4 Elap
se Techn
olo
gies
Ce que l’on obtient généralement
Hiérarchie minceDesign basé sur
les rôlesAbstraction
(rôles)
Nommage clair pour l’appelant
Possible meilleur respect des
principes OO
© 2
01
4 Elap
se Techn
olo
gies
Désavantages de l’approche mockiste
Couplage du test avec la signature
des collaborateursFragiliser 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)
© 2
01
4 Elap
se Techn
olo
gies
La bonne question…
Que voulez-vous maximiser ?
© 2
01
4 Elap
se Techn
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
4 Elap
se Techn
olo
gies
Rappel: TDD et architecture
+ Code testable
+ de « design »
simple?
- de code couplé
+ de code réutilisable
+ d’architecture émergeante
© 2
01
4 Elap
se Techn
olo
gies
Pour aller plus loin…
Image de anamkkml/ FreeDigitalPhotos.net et github.com
Code sourcehttps://github.com/fbourbonnais/propulsez-architecture-tdd-mocks
Diapositiveshttp://developpementagile.com/architecture-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
© 2
01
4 Elap
se Techn
olo
gies
Mer
ciMon nom
Félix-Antoine Bourbonnais
Notre bloguedeveloppementagile.com
Notre siteelapsetech.com
Mon Twitter@fbourbonnais
Mon LinkedInlinkedin.com/in/fbourbonnais/fr
© 2
01
4 Elap
se Techn
olo
gies
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
© 2
01
4 Elap
se Techn
olo
gies
Références
© 2
01
4 Elap
se Techn
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
4 Elap
se Techn
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