Propulsez votre architecture
grâce au TDD et aux Mocks
FÉLIX-ANTOINE BOURBONNAIS
ING.JR, PSM, M.SC.
Agile Montréal
12 mars...
©2014ElapseTechnologies
Image de Eyesplash
http://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benv...
Félix-Antoine Bourbonnais
Ing. jr, PSM, M.Sc.
www.elapsetech.com
Formation – Accompagnement – Conseils
fbourbonnais@elapse...
©2014ElapseTechnologies
Avertissement
Cette présentation s’adresse
principalement à un public ayant déjà
expérimenté le TD...
©2014ElapseTechnologies
Réchauffement…
Qui fait du TDD?
Qui utilise des Mocks?
Quelles sont vos
attentes?
Images de Idea G...
©2014ElapseTechnologies
DOUBLURES ET MOCKS
Rappel sur les
©2014ElapseTechnologies
Rappel: les tests unitaires
©2014ElapseTechnologies
Rappel: les Mocks
CUT
Test
CUT
A
B
X
N
©2014ElapseTechnologies
Rappel: les mocks
C
Test
C
A
B
X
N
©2014ElapseTechnologies
Rappel: les mocks
C
Test
C
A’
B’
A’’
Lance
IOException
Retourne
[1]
©2014ElapseTechnologies
TDD
Rappels des fondements du
©2014ElapseTechnologies
Technique ou discipline?
Le TDD est une discipline
©2014ElapseTechnologies
Rappel: Le cycle du TDD
Écrire un
test qui
échoue
Faire
passer le
test
Réusiner
On passe à la phas...
©2014ElapseTechnologies
Shu-Ha-Ri
L’élève suit
l’enseignement
d’un maître
SHU
Il apprend
de d’autres
maîtres
(écoles)
HA
I...
©2014ElapseTechnologies
TDD « CLASSIQUE »
Le design et le
Image: posterize / FreeDigitalPhotos.net
©2014ElapseTechnologies
TDD classique
Centré sur l’état
et le résultat final
Image: nuchylee / FreeDigitalPhotos.net
©2014ElapseTechnologies
TDD classique
Extraction des types
Classe
P Classe
R1
PTest
Division
R1Test
Classe
P
PTest
Mock
R1
©2014ElapseTechnologies
TDD classique
En résumé
TDD
Classique
Évolution du
« design »
•Par division
•Extraction
Problèmes
...
©2014ElapseTechnologies
L’ORIENTATION OBJET
Rappel de
©2014ElapseTechnologies
InfrastructureDomaineUI
Messages et collaboration
Classe
ACtrl
Collaboration des objets  fonction...
©2014ElapseTechnologies
Le « Tell don’t Ask »
getAmi(joe)
.getCorps()
.getJambe(Orient.GAUCHE)
.setPosition(
sol + 5,
cent...
©2014ElapseTechnologies
Pourquoi le « Tell don’t ask »
Cacher le
« comment »
Limiter l’effet
des
modifications
Limiter l’e...
©2014ElapseTechnologies
Stimulus
Un objet est une boîte noire
Classe
Réception d’un message
Envoi d’un message à
un collab...
©2014ElapseTechnologies
PILOTER SON DESIGN AVEC DES MOCKS?
Comment
Image: jscreationzs / FreeDigitalPhotos.net
©2014ElapseTechnologies
Le TDD « Mockiste »
Centré sur les interactions et comportements
entre les objets considérant leur...
©2014ElapseTechnologies
Le TDD « Mockiste »
Utilise les Mocks comme pierre angulaire
Images: cooldesign/ freedigitalphotos...
©2014ElapseTechnologies
TDD « Mockiste »
Extraction des types
Découverte des types par les Mocks
Définition de l’interface...
©2014ElapseTechnologies
TDD piloté par les Mocks
Identifier les rôles
Viewer
<<Interface>>
Loader
Viewer
Test
Découverte p...
©2014ElapseTechnologies
TDD piloté par les Mocks
Arriver à destination…
Test
acceptation
Viewer
UTest
Terminé
<<Interface>...
©2014ElapseTechnologies
En résumé
Quelle est la responsabilité de
l’objet testé ?
De quoi est-ce que l’objet a besoin
pour...
©2014ElapseTechnologies
Exemple
banque.acheter(carte, marchand, montant)
--> carte.crediter(montant)
--> marchand.debiter(...
©2014ElapseTechnologies
DÉMONSTRATION
Présentation de la
Image: Stuart Miles / freedigitalphotos.net
©2014ElapseTechnologies
Démonstration
Soumissions à une conférence
#1 Soumission d’une présentation
En tant que soumission...
©2014ElapseTechnologies
CONCLUSION et RÉSUMÉ
©2014ElapseTechnologies
Approche « outside-in »
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastructure
Dupl...
©2014ElapseTechnologies
Piloter le design par les mocks
Image: Simon Howden / FreeDigitalPhotos.net
UI
Domaine
Infrastruct...
©2014ElapseTechnologies
Avantages de l’approche mockiste
Favorise le
« Tell don’t ask »
Moins de
« trains d’appels »
(Deme...
©2014ElapseTechnologies
Avantages de l’approche mockiste
Développement piloté
par les besoins
(need-driven)
Définir les in...
©2014ElapseTechnologies
Ce que l’on obtient généralement
Hiérarchie mince
Design basé sur
les rôles
Abstraction
(rôles)
No...
©2014ElapseTechnologies
Désavantages de l’approche mockiste
Couplage du test
avec la signature
des collaborateurs
Fragilis...
©2014ElapseTechnologies
La bonne question…
Que voulez-vous
maximiser ?
©2014ElapseTechnologies
Complémentarité
Cette école doit être combinée!
Alterner entre les techniques
apporte généralement...
©2014ElapseTechnologies
Rappel: TDD et architecture
+
Code testable
+ de
« design »
simple?
- de code
couplé
+ de code
réu...
©2014ElapseTechnologies
Pour aller plus loin…
Image de anamkkml/ FreeDigitalPhotos.net et github.com
Code source
https://g...
©2014ElapseTechnologies
Merci Mon nom
Félix-Antoine Bourbonnais
Notre blogue
developpementagile.com
Notre site
elapsetech....
©2014ElapseTechnologies
Elapse Technologies
Formation
Accompagnement (coaching)
Mentorat virtuel
Conseils et diagnostics
A...
©2014ElapseTechnologies
Références
©2014ElapseTechnologies
Références
Steve Freeman, Tim Mackinnon, Nat Pryce, et Joe Walnes.
Mock roles, Not objects. p. 236...
©2014ElapseTechnologies
Références
Steve Freeman, Sustainable Test-Driven Development. QCon San Francisco
2009.
http://www...
Prochain SlideShare
Chargement dans…5
×

Propulsez votre architectures grâce au TDD et aux Mocks (Agile Montréal 2014)

2 156 vues

Publié le

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.

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 156
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 701
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Propulsez votre architectures grâce au TDD et aux Mocks (Agile Montréal 2014)

  1. 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. 2. ©2014ElapseTechnologies Image de Eyesplash http://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benvenuto.jpg
  3. 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. 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. 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. 6. ©2014ElapseTechnologies DOUBLURES ET MOCKS Rappel sur les
  7. 7. ©2014ElapseTechnologies Rappel: les tests unitaires
  8. 8. ©2014ElapseTechnologies Rappel: les Mocks CUT Test CUT A B X N
  9. 9. ©2014ElapseTechnologies Rappel: les mocks C Test C A B X N
  10. 10. ©2014ElapseTechnologies Rappel: les mocks C Test C A’ B’ A’’ Lance IOException Retourne [1]
  11. 11. ©2014ElapseTechnologies TDD Rappels des fondements du
  12. 12. ©2014ElapseTechnologies Technique ou discipline? Le TDD est une discipline
  13. 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. 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. 15. ©2014ElapseTechnologies TDD « CLASSIQUE » Le design et le Image: posterize / FreeDigitalPhotos.net
  16. 16. ©2014ElapseTechnologies TDD classique Centré sur l’état et le résultat final Image: nuchylee / FreeDigitalPhotos.net
  17. 17. ©2014ElapseTechnologies TDD classique Extraction des types Classe P Classe R1 PTest Division R1Test Classe P PTest Mock R1
  18. 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. 19. ©2014ElapseTechnologies L’ORIENTATION OBJET Rappel de
  20. 20. ©2014ElapseTechnologies InfrastructureDomaineUI Messages et collaboration Classe ACtrl Collaboration des objets  fonctionnalité Classe B Classe C Iface E Classe Persist Classe D
  21. 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. 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. 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. 24. ©2014ElapseTechnologies PILOTER SON DESIGN AVEC DES MOCKS? Comment Image: jscreationzs / FreeDigitalPhotos.net
  25. 25. ©2014ElapseTechnologies Le TDD « Mockiste » Centré sur les interactions et comportements entre les objets considérant leur rôle
  26. 26. ©2014ElapseTechnologies Le TDD « Mockiste » Utilise les Mocks comme pierre angulaire Images: cooldesign/ freedigitalphotos.net
  27. 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. 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. 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. 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. 31. ©2014ElapseTechnologies Exemple banque.acheter(carte, marchand, montant) --> carte.crediter(montant) --> marchand.debiter(montant)
  32. 32. ©2014ElapseTechnologies DÉMONSTRATION Présentation de la Image: Stuart Miles / freedigitalphotos.net
  33. 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. 34. ©2014ElapseTechnologies CONCLUSION et RÉSUMÉ
  35. 35. ©2014ElapseTechnologies Approche « outside-in » Image: Simon Howden / FreeDigitalPhotos.net UI Domaine Infrastructure Duplication? Réusinage TDD
  36. 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. 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. 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. 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. 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. 41. ©2014ElapseTechnologies La bonne question… Que voulez-vous maximiser ?
  42. 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. 43. ©2014ElapseTechnologies Rappel: TDD et architecture + Code testable + de « design » simple? - de code couplé + de code réutilisable + d’architecture émergeante
  44. 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. 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. 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. 47. ©2014ElapseTechnologies Références
  48. 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. 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

×