Propulser votre architecture grâce aux mocks

2 415 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 415
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 785
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  

×