• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Propulser votre architecture grâce aux mocks
 

Propulser votre architecture grâce aux mocks

on

  • 2,330 views

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

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

Statistics

Views

Total Views
2,330
Views on SlideShare
673
Embed Views
1,657

Actions

Likes
0
Downloads
17
Comments
0

7 Embeds 1,657

http://www.elapsetech.com 990
http://developpementagile.com 410
http://elapsetech.com 213
http://elapse.local 35
http://developpementagile.local 6
http://translate.googleusercontent.com 2
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Propulser votre architecture grâce aux mocks Propulser votre architecture grâce aux mocks Presentation Transcript

    • Propulsez  votre  architecture   grâce  aux  mocks   Confoo  2012   Montréal,  Québec,  Canada   2  mars  2012  
    • 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
    • Réchauffement…   Quelles  sont  vos   aXentes?   Qui  fait  du  TDD?   Qui  uKlise  des  Mocks?   3
    • Comment  découvrir  l’architecture?   Mocks   TDD  
    • J’uKlise  déjà  des  mocks!   On  va  parler  des  mocks  pour  piloter  la   découverte  du  design!  Image: graur codrin / FreeDigitalPhotos.net
    • IntroducKon  aux  TESTS  
    • Plusieurs  types  de  tests   IntégraKon   Bout-­‐en-­‐ AcceptaKon   bout   Système   Unitaire   …  Images: Renjith Krishnan, Salvatore Vuono, Jscreationzs, Photostock, Posterize / FreeDigitalPhotos.net
    • 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’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
    • IntroducKon  au  TDD  
    • 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
    • Pourquoi  faire  du  TDD  La  peur  du  changement…   Peur  =  î  maintenabilité  Image:  David  CasKllo  Dominici  /  FreeDigitalPhotos.net   16
    • 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
    • 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  
    • Rappel  de  L’ORIENTATION  OBJET  
    • Messages  et  collaboraKon   Classe   C   Classe   B   Classe   Classe   D   A   Classe   Classe   E   F   UI   Domaine   Infrastructure   Collabora*on  des  objets  à  fonc*onnalité    
    • 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  à  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  »  
    • 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  
    • Le  design  et  le   TDD  «  CLASSIQUE  »  Image: posterize / FreeDigitalPhotos.net
    • TDD  classique   Centré  sur  l’état  et  le  résultat  final.  Image: nuchylee / FreeDigitalPhotos.net
    • TDD  classique  ExtracKon  des  types   Classe   Division   P   Classe   Classe   P   R1   Mock   R1   PTest   PTest   R1Test  
    • Comment   PILOTER  SON  DESIGN  AVEC  DES   MOCKS?  Image: jscreationzs / FreeDigitalPhotos.net
    • 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  
    • 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  
    • TDD  piloté  par  les  Mocks  Arriver  à  desKnaKon…   Test   <<Interface>>   <<Interface>>   acceptaKon   Viewer   Loader   FileReader   UTest   Utest   Classe   Fake   Utest   PNGLoader   FileReader   Terminé  
    • ÉvoluKon  du  design   Réusinage   •  InteracKons   •  Signatures   •  …  
    • 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)
    • 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
    • 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  
    • 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
    • Approche  «  top-­‐down  »   UI   Réusinage   Domaine   Infrastructure   TDD   DuplicaKon?  Image: Simon Howden / FreeDigitalPhotos.net
    • 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
    • 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.  
    • PrésentaKon  de  la  DÉMONSTRATION  
    • 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
    • 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
    • Période  de  QUESTIONS   42
    • Références  
    • 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  
    • 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