Propulsez	  votre	  architecture	       grâce	  aux	  mocks	               Confoo	  2012	       Montréal,	  Québec,	  Cana...
Félix-­‐Antoine	  Bourbonnais	  	  Ing.	  jr,	  PSM-­‐I	  !   Formateur	  et	  Coach	  Agile	  !   Enseignement	  et	  for...
Réchauffement…	                 Quelles	  sont	  vos	                   aXentes?	                 Qui	  fait	  du	  TDD?	  ...
Comment	  découvrir	  l’architecture?	                 Mocks	                             TDD	  
J’uKlise	  déjà	  des	  mocks!	                On	  va	  parler	  des	  mocks	  pour	  piloter	  la	                      ...
IntroducKon	  aux	  TESTS	  
Plusieurs	  types	  de	  tests	                                                                                    Intégra...
Tests	  unitaires	  But:	  tester	  les	  modules	  en	  isola*on.	  
IntroducKon	  aux	  DOUBLURES	  ET	  MOCKS	  
onctionnementtème   FoncKonnement	                             10
tionnement  FoncKonnement	                        11
ionnement  FoncKonnement	                        12
UKlisaKons	    Piloter	  (simuler	  un	  cas)	    •  Simuler	  un	  cas	  précis	  dans	  un	  objet	  uKlisé	  par	  l’ob...
IntroducKon	  au	  TDD	  
Cycle	  du	  TDD	                              Écrire	  un	                1	                                             ...
Pourquoi	  faire	  du	  TDD	  La	  peur	  du	  changement…	                                                               ...
Focaliser	  sur	  le	  «	  QUOI	  »	               Se	  placer	  en	  posiKon	  d’uKlisateur	  du	  code	                 ...
TDD	  et	  architecture	  !   Favorise	  l’écriture	  de	  code	  testable	  !   Offre	  une	  rétroacKon	  concernant	  la...
Rappel	  de	  L’ORIENTATION	  OBJET	  
Messages	  et	  collaboraKon	                                          Classe	                                            ...
Le	  «	  Tell	  don’t	  Ask	  »	  Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
Pourquoi	  le	  «	  Tell	  don’t	  ask	  »	  !   Cacher	  le	  «	  comment	  »	  !   Limiter	  l’effet	  des	  modificaKons	...
Un	  objet	  est	  une	  boîte	  noire	  SKmulus	                RécepKon	  d’un	  message	                               ...
Le	  design	  et	  le	      TDD	  «	  CLASSIQUE	  »	  Image: posterize / FreeDigitalPhotos.net
TDD	  classique	                   Centré	  sur	  l’état	  et	  le	  résultat	  final.	  Image: nuchylee / FreeDigitalPhoto...
TDD	  classique	  ExtracKon	  des	  types	                Classe	          Division	                   P	                 ...
Comment	      PILOTER	  SON	  DESIGN	  AVEC	  DES	      MOCKS?	  Image: jscreationzs / FreeDigitalPhotos.net
TDD	  piloté	  par	  les	  Mocks	  Tirer	  à	  parKr	  des	  besoins	  	                                                  ...
TDD	  piloté	  par	  les	  Mocks	  IdenKfier	  les	  rôles	  requis	  (dépendances)	  par	  le	  module	  testé	           ...
TDD	  piloté	  par	  les	  Mocks	  Arriver	  à	  desKnaKon…	          Test	                                          <<Int...
ÉvoluKon	  du	  design	                              Réusinage	                  •  InteracKons	                  •  Signa...
En	  résumé	  1.  Établir	  quelle	  est	  la	  responsabilité	  de	  l’objet	  testé	  2.  De	  quoi	  est-­‐ce	  que	  l...
Avantages	  !   Favorise	  le	  respect	  du	  «	  Tell	  don’t	  ask	  »	  !   Permet	  de	  définir	  les	  interface	  à...
Ce	  que	  l’on	  obKent	  généralement	  !   Hiérarchie	  mince	  !   Design	  basé	  sur	  les	  rôles	  !   AbstracKon	...
Désavantages	  !   Ne	  permet	  pas	  d’établir	  le	  «	  comment	  »	  !   Peut	  résulter	  en	  une	  trop	  grande	 ...
Approche	  «	  top-­‐down	  »	                         UI	                                                Réusinage	      ...
Piloter	  le	  design	  par	  les	  mocks	      MyLibraryView	                                         LibraryRealTime    ...
Favoriser	  la	  détecKon	  des	  mauvaises	  odeurs...	  !   Beaucoup	  de	  Mocks	       o  Couplage…	  !   Difficile	  d’...
PrésentaKon	  de	  la	  DÉMONSTRATION	  
Complémentarité	  !   CeXe	  technique	  doit	      être	  combinée!	  !   Alterner	  entre	  les	      techniques	  appor...
Téléchargement	                              Évaluez	  la	  présentaKon	  sur:	                                           ...
Période	  de	  QUESTIONS	                      42
Références	  
Références	  !   Steve	  Freeman,	  Tim	  Mackinnon,	  Nat	  Pryce,	  et	  Joe	  Walnes.	  	      Mock	  roles,	  Not	  ob...
Références	  !   Steve	  Freeman,	  Sustainable	  Test-­‐Driven	  Development.	  QCon	  San	  Francisco	      2009.	  	   ...
Prochain SlideShare
Chargement dans…5
×

Propulser votre architecture grâce aux mocks

2 436 vues

Publié le

Présentation de Félix-Antoine Bourbonnais expliquant comment les mocks peuvent piloter votre design.

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

  • Soyez le premier à aimer ceci

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

Aucune remarque pour cette diapositive

Propulser votre architecture grâce aux mocks

  1. 1. Propulsez  votre  architecture   grâce  aux  mocks   Confoo  2012   Montréal,  Québec,  Canada   2  mars  2012  
  2. 2. Félix-­‐Antoine  Bourbonnais    Ing.  jr,  PSM-­‐I  !   Formateur  et  Coach  Agile  !   Enseignement  et  formaKons     o  TDD,  Réusinage,  OO  avancé,     AOP,  tests,  Scrum  !   Recherches     o  AOP,  agilité,  tests  et  mocks  !   Développeur     @Uourbonnais   o  Java  et  Python  (principalement)   2
  3. 3. Réchauffement…   Quelles  sont  vos   aXentes?   Qui  fait  du  TDD?   Qui  uKlise  des  Mocks?   3
  4. 4. Comment  découvrir  l’architecture?   Mocks   TDD  
  5. 5. J’uKlise  déjà  des  mocks!   On  va  parler  des  mocks  pour  piloter  la   découverte  du  design!  Image: graur codrin / FreeDigitalPhotos.net
  6. 6. IntroducKon  aux  TESTS  
  7. 7. Plusieurs  types  de  tests   IntégraKon   Bout-­‐en-­‐ AcceptaKon   bout   Système   Unitaire   …  Images: Renjith Krishnan, Salvatore Vuono, Jscreationzs, Photostock, Posterize / FreeDigitalPhotos.net
  8. 8. Tests  unitaires  But:  tester  les  modules  en  isola*on.  
  9. 9. IntroducKon  aux  DOUBLURES  ET  MOCKS  
  10. 10. onctionnementtème FoncKonnement   10
  11. 11. tionnement FoncKonnement   11
  12. 12. ionnement FoncKonnement   12
  13. 13. UKlisaKons   Piloter  (simuler  un  cas)   •  Simuler  un  cas  précis  dans  un  objet  uKlisé  par  l’objet  testé.     •  Exemple:     Simuler  une  excepKon  lancée.   Vérifier  un  comportement   •  Vérifier  que  l’objet  testé  a  eu  l’effet  désiré  sur  un  autre  objet.     •  Exemple:   Vérifier  que  la  méthode  a  été  appelée  sur  un  autre  objet.   13
  14. 14. IntroducKon  au  TDD  
  15. 15. Cycle  du  TDD   Écrire  un   1   On  passe  à  la  phase   test  qui   «  VERTE  »  dès  qu’on  a  un   échoue   test  qui  échoue.   Erreur  de  compilateur   =  «  échec  ».   Faire  1   Réusiner   passer  le   test   2   On  passe  à  la  phase  «  Réusinage  »   dès  que  le  test  passe.   15
  16. 16. Pourquoi  faire  du  TDD  La  peur  du  changement…   Peur  =  î  maintenabilité  Image:  David  CasKllo  Dominici  /  FreeDigitalPhotos.net   16
  17. 17. Focaliser  sur  le  «  QUOI  »   Se  placer  en  posiKon  d’uKlisateur  du  code   Se  concentrer  sur  le  «  QUOI  »   «  Instead  of  just  using  tesKng  to  verify  our  work  aker  it’s  done,  TDD  turns   tesKng  into  a  design  ac*vity.  [1]  »   «  We  use  the  tests  to  clarify  our  ideas  about  what  we  want  the   code  to  do.  [1]»      [1]  Steve  Freeman  et  Nat  Pryce.  Growing  Object-­‐Oriented  So2ware,  Guided  by  Tests.  Addison-­‐Wesley  Professional,  1  ediKon,  Octobre  2009.     17
  18. 18. TDD  et  architecture  !   Favorise  l’écriture  de  code  testable  !   Offre  une  rétroacKon  concernant  la  facilité   d’uKlisaKon  du  «  design  »  !   Favorise  l’écriture  de  code  faiblement  couplé  !   Favorise  l’écriture  de  code  réuKlisable  !   Favorise  l’évoluKon  de  l’architecture  et  la   découverte  progressive   o  Colle  à  la  réalité  et  aux  besoins  présents  
  19. 19. Rappel  de  L’ORIENTATION  OBJET  
  20. 20. Messages  et  collaboraKon   Classe   C   Classe   B   Classe   Classe   D   A   Classe   Classe   E   F   UI   Domaine   Infrastructure   Collabora*on  des  objets  à  fonc*onnalité    
  21. 21. Le  «  Tell  don’t  Ask  »  Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
  22. 22. Pourquoi  le  «  Tell  don’t  ask  »  !   Cacher  le  «  comment  »  !   Limiter  l’effet  des  modificaKons  à  la  logique   (algorithme)  !   Éviter  les  «  trains  »  d’appels  !   Réduire  la  duplicaKon  !   Laisser  les  objets  «  s’occuper  de  leurs  oignons  »  !   Éviter  les  «  domaines  anémiques  »  
  23. 23. Un  objet  est  une  boîte  noire  SKmulus   RécepKon  d’un  message   Envoi  d’un  message  à   un  collaborateur   Effet   Classe   Envoi  d’un  message  à   un  collaborateur  Effet   Retour  d’une  réponse  
  24. 24. Le  design  et  le   TDD  «  CLASSIQUE  »  Image: posterize / FreeDigitalPhotos.net
  25. 25. TDD  classique   Centré  sur  l’état  et  le  résultat  final.  Image: nuchylee / FreeDigitalPhotos.net
  26. 26. TDD  classique  ExtracKon  des  types   Classe   Division   P   Classe   Classe   P   R1   Mock   R1   PTest   PTest   R1Test  
  27. 27. Comment   PILOTER  SON  DESIGN  AVEC  DES   MOCKS?  Image: jscreationzs / FreeDigitalPhotos.net
  28. 28. TDD  piloté  par  les  Mocks  Tirer  à  parKr  des  besoins     B   Capacité  de  B  et  C     A   Besoins  de  A   (services)   C   Tirer  les  types  à  parKr  de  la  demande  
  29. 29. TDD  piloté  par  les  Mocks  IdenKfier  les  rôles  requis  (dépendances)  par  le  module  testé   Viewer <<Interface>>   <<Interface>>   Test   Viewer   ?  Loader   FileReader   Mock   Mock   PNGLoader Classe   Test   ?   PNGLoader   Découverte  pas  à  pas   Tirer  les  types  à  parKr  de  la  demande  
  30. 30. TDD  piloté  par  les  Mocks  Arriver  à  desKnaKon…   Test   <<Interface>>   <<Interface>>   acceptaKon   Viewer   Loader   FileReader   UTest   Utest   Classe   Fake   Utest   PNGLoader   FileReader   Terminé  
  31. 31. ÉvoluKon  du  design   Réusinage   •  InteracKons   •  Signatures   •  …  
  32. 32. 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)
  33. 33. Avantages  !   Favorise  le  respect  du  «  Tell  don’t  ask  »  !   Permet  de  définir  les  interface  à  parKr  des  besoins   o  Force  à  se  concentrer  sur  le  «  Quoi  »  avant  le   «  Comment  »   o  On  définit  d’abord  le  «  Quoi  »  à  parKr  des  tests  des  autres  !   Retarde  les  décisions  d’implémentaKons  !   Favorise  un  design  testable  !   L’isolaKon  favorise  le  réusinage   33
  34. 34. Ce  que  l’on  obKent  généralement  !   Hiérarchie  mince  !   Design  basé  sur  les  rôles  !   AbstracKon  (sous  la  forme  de  rôles)  !   Nommage  en  posiKon  d’uKlisateur   o  Méthodes  et  types  !   Meilleur  respect  du  «  Tell  don’t  ask  »  !   Parfois  moins  de  temps  en  déverminage  pour   trouver  le  problème  lorsqu’un  test  ne  passe  plus  
  35. 35. Désavantages  !   Ne  permet  pas  d’établir  le  «  comment  »  !   Peut  résulter  en  une  trop  grande  séparaKon   o  Trop  de  classes/interfaces  !   FoncKonne  moins  bien  sur  les  systèmes  basés  sur  les   données   35
  36. 36. Approche  «  top-­‐down  »   UI   Réusinage   Domaine   Infrastructure   TDD   DuplicaKon?  Image: Simon Howden / FreeDigitalPhotos.net
  37. 37. Piloter  le  design  par  les  mocks   MyLibraryView   LibraryRealTime !   Composer  à  parKr  des   View   …Presenter   …Presenter   interacKons   UI   !   PosiKon  «  uKlisateur  »  Mock   OnlineLibrary   Book   !   ExploraKons  successives   (étape  par  étape)   Mock   LibraryProvider   !   Reporter  les  décisions   Domaine   d’implémentaKons   OnlineService   !   Explorer  sans  trop  se   compromeXre   Infrastructure  Image: Simon Howden / FreeDigitalPhotos.net
  38. 38. Favoriser  la  détecKon  des  mauvaises  odeurs...  !   Beaucoup  de  Mocks   o  Couplage…  !   Difficile  d’injecter  les  Mocks   o  Pourquoi  les  dépendances  ne  sont  pas  passées?   o  Patron  «  Factory  »?  !   Paramètres  mulKples  (constructeurs  et  méthodes)   o  ExtracKon  d’un  concept?  !   Incapable  de  trouver  un  nom  !   Etc.  
  39. 39. PrésentaKon  de  la  DÉMONSTRATION  
  40. 40. Complémentarité  !   CeXe  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)   40
  41. 41. Téléchargement   Évaluez  la  présentaKon  sur:   hXps://joind.in/6106   Téléchargez  les  diaposiKves  complètes  sur   developpementagile.com  Image: rajcreationzs / FreeDigitalPhotos.ne 41
  42. 42. Période  de  QUESTIONS   42
  43. 43. Références  
  44. 44. 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   hXp://www.infoq.com/presentaKons/Mock-­‐Objects-­‐Nat-­‐Pryce-­‐ Steve-­‐Freeman  !   MarKn  Fowler,  Mocks  Aren’t  Stubs,  2  janvier  2007.     [Résumé  des  approches]   hXp://marKnfowler.com/arKcles/mocksArentStubs.html  
  45. 45. Références  !   Steve  Freeman,  Sustainable  Test-­‐Driven  Development.  QCon  San  Francisco   2009.     hXp://www.infoq.com/presentaKons/Sustainable-­‐Test-­‐Driven-­‐ Development  ! Codemanship  presents...  Classic  TDD  vs.  London  School,  2011.    [CriKqué]   hXp://www.youtube.com/watch?v=AUE155LISV4  !   Michael  Feathers  et  Steve  Freeman.  Michael  Feathers  and  Steve  Freeman   on  Design,  InfoQ  at  QCon  San  Francisco  2009   hXp://www.infoq.com/interviews/feathers-­‐freeman-­‐design  !   Discussion  –  «  Classic  TDD  or  «  London  School  »  -­‐  any  opinions/comments/ elaboraPon  on  Jason  Gorman’s  post?  »  GOOS  Mailinglist,  2011.     hXps://groups.google.com/d/topic/growing-­‐object-­‐oriented-­‐sokware/ dOmOIafFDcI/discussion  

×