Pro Yearly is on sale from $80 to $50! »

Propulsez votre architecture grâce au TDD et aux Mocks (Agile Québec 2013)

Propulsez votre architecture grâce au TDD et aux Mocks (Agile Québec 2013)

La communauté a découvert depuis un certain temps des pratiques permettant de maximiser l'émergence du design (architecture) via le TDD. Mais comment faire? Cette présentation explique comment tirer le maximum de vos tests unitaires et de vos «mocks» à l'aide de l'approche «Mockiste» (TDD de Londres). Nous verrons comment les mocks peuvent aider à concevoir une architecture ayant une meilleure conception orientée objet.

La séance prendra la forme d'un tutoriel (démonstration) avancé en réalisant pas à pas un design simple parsemé de trucs et astuces.

Code source: https://github.com/fbourbonnais/propulsez-architecture-tdd-mocks

Transcript

  1. © 2012 Elapse Technologies © 2013 Elapse Technologies © 2013

    Elapse Technologies Propulsez votre architecture grâce au TDD et aux mocks Agile Québec 12 juin 2013 nasa.gov
  2. © 2013 Elapse Technologies © 2013 Elapse Technologies Avertissement Cette

    présentation est de niveau « avancé »
  3. © 2013 Elapse Technologies © 2013 Elapse Technologies Félix-Antoine Bourbonnais

    Formateur & Coach Agile o Tests automatisés: TDD, ATDD, BDD o Orientation objet avancée o Architecture agile o Réusinage et qualité (Clean Code) o Agile et Scrum Concepteur de logiciels o Pratiques de développement o Java, Python, etc. @fbourbonnais linkedin.com/in/fbourbonnais/fr elapsetech.com/fab www.elapsetech.com fbourbonnais@elapsetech.com
  4. © 2013 Elapse Technologies © 2013 Elapse Technologies Réchauffement… Qui

    fait du TDD? Qui utilise des Mocks? Quelles sont vos attentes? Images de: Idea Go / freedigitalphotos.net Rameshng / Flickr.com
  5. © 2013 Elapse Technologies © 2013 Elapse Technologies Comment découvrir

    l’architecture? TDD Mocks
  6. © 2013 Elapse Technologies © 2013 Elapse Technologies DOUBLURES ET

    MOCKS Rappel sur les
  7. © 2013 Elapse Technologies © 2013 Elapse Technologies Rappel: les

    tests unitaires But: tester les modules en isolation.
  8. © 2013 Elapse Technologies © 2013 Elapse Technologies Rappel: les

    mocks CUT Test CUT A B X N
  9. © 2013 Elapse Technologies © 2013 Elapse Technologies Rappel: les

    mocks C Test C A B X N
  10. © 2013 Elapse Technologies © 2013 Elapse Technologies Rappel: les

    mocks C Test C A’ B’ A’’ Lance IOException Retourne [1]
  11. © 2013 Elapse Technologies © 2013 Elapse Technologies TDD Rappels

    des fondements du
  12. © 2013 Elapse Technologies © 2013 Elapse Technologies Technique ou

    discipline? Le TDD est une discipline
  13. © 2013 Elapse Technologies © 2013 Elapse Technologies 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 3
  14. © 2013 Elapse Technologies © 2013 Elapse Technologies 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. © 2013 Elapse Technologies © 2013 Elapse Technologies TDD «

    CLASSIQUE » Le design et le Image: posterize / FreeDigitalPhotos.net
  16. © 2013 Elapse Technologies © 2013 Elapse Technologies TDD classique

    Image: nuchylee / FreeDigitalPhotos.net Centré sur l’état et le résultat final
  17. © 2013 Elapse Technologies © 2013 Elapse Technologies TDD classique

    Extraction des types Classe P Classe R1 PTest Division R1Test Classe P PTest Mock R1
  18. © 2013 Elapse Technologies © 2013 Elapse Technologies Le TDD

    classique TDD Classique Évolution du « design » •Par division •Extraction Problèmes algorithmiques •Traitement de données •Calculs Valide l’état
  19. © 2013 Elapse Technologies © 2013 Elapse Technologies L’ORIENTATION OBJET

    Rappel de
  20. © 2013 Elapse Technologies © 2013 Elapse Technologies Infrastructure Domaine

    UI Messages et collaboration Classe ACtrl Collaboration des objets  fonctionnalité Classe B Classe C Iface E Classe Persist Classe D
  21. © 2013 Elapse Technologies © 2013 Elapse Technologies Le «

    Tell don’t Ask » Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
  22. © 2013 Elapse Technologies © 2013 Elapse Technologies 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. © 2013 Elapse Technologies © 2013 Elapse Technologies 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. © 2013 Elapse Technologies © 2013 Elapse Technologies PILOTER SON

    DESIGN AVEC DES MOCKS? Comment Image: jscreationzs / FreeDigitalPhotos.net
  25. © 2013 Elapse Technologies © 2013 Elapse Technologies Le TDD

    « Mockiste » Centré sur les interactions et comportements entre les objets considérant leur rôle Images: sheelamohan / freedigitalphotos.net
  26. © 2013 Elapse Technologies © 2013 Elapse Technologies Le TDD

    « Mockiste » Utilise les Mocks comme pierre angulaire Images: cooldesign/ freedigitalphotos.net
  27. © 2013 Elapse Technologies © 2013 Elapse Technologies Évolution du

    « design » Par le raffinement Découverte des types par les Mocks Définition de l’interface à partir des besoins établis dans les autres tests grâce aux mocks. TDD « Mockiste »
  28. © 2013 Elapse Technologies © 2013 Elapse Technologies TDD piloté

    par les Mocks Identifier les rôles requis (dépendances) par le module testé 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. © 2013 Elapse Technologies © 2013 Elapse Technologies TDD piloté

    par les Mocks Arriver à destination… Test acceptation Viewer UTest Terminé <<Interface>> Loader Classe PNGLoader Utest <<Interface>> FileReader Fake FileReader Utest
  30. © 2013 Elapse Technologies © 2013 Elapse Technologies En résumé

    Quels effets aura ce comportement sur l’environnement immédiat? De quoi est-ce que l’objet a besoin pour réaliser son travail en terme de rôles ? Quelle est la responsabilité de l’objet testé ? Classe testée (CUT) A Besoin de (rôle) B Effet sur Responsabilité
  31. © 2013 Elapse Technologies © 2013 Elapse Technologies Exemple banque.acheter(carte,

    marchand, montant) --> carte.crediter(montant) --> marchand.debiter(montant)
  32. © 2013 Elapse Technologies © 2013 Elapse Technologies DÉMONSTRATION Présentation

    de la Image: Stuart Miles / freedigitalphotos.net
  33. © 2013 Elapse Technologies © 2013 Elapse Technologies 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 Démonstration
  34. © 2013 Elapse Technologies © 2013 Elapse Technologies Approche «

    outside-in » Image: Simon Howden / FreeDigitalPhotos.net UI Domaine Infrastructure Duplication? Réusinage TDD
  35. © 2013 Elapse Technologies © 2013 Elapse Technologies Piloter le

    design par les mocks Composer à partir des interactions Position « utilisateur » Explorations successives (étape par étape) Reporter les décisions d’implémentations Explorer sans trop se compromettre Image: Simon Howden / FreeDigitalPhotos.net UI Domaine Infrastructure MyLibraryView …Presenter OnlineLibrary Book LibraryProvider LibraryRealTime View …Presenter OnlineService Moc k Moc k
  36. © 2013 Elapse Technologies © 2013 Elapse Technologies 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
  37. © 2013 Elapse Technologies © 2013 Elapse Technologies 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 »
  38. © 2013 Elapse Technologies © 2013 Elapse Technologies 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 Meilleur respect des principes OO
  39. © 2013 Elapse Technologies © 2013 Elapse Technologies Désavantages de

    l’approche mockiste Couplage du test avec la signature des collaborateurs Fonctionne mal avec des problèmes algorithmiques Génère beaucoup de mocks et d’interfaces Danger: Trop focaliser sur le UI (outside-in) Tests unitaires => aucun test intégré de bas niveau.
  40. © 2013 Elapse Technologies © 2013 Elapse Technologies La Bonne

    question… Que voulez-vous maximiser ?
  41. © 2013 Elapse Technologies © 2013 Elapse Technologies 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
  42. © 2013 Elapse Technologies © 2013 Elapse Technologies Mauvaises odeurs

    détectables Mauvaise odeurs avec les mocks Beaucoup de Mocks Couplage… Difficile de les injecter OCP ? Patron « Factory »? Beaucoup de paramètres Extraction d’un concept? …
  43. © 2013 Elapse Technologies © 2013 Elapse Technologies Rappel: TDD

    et architecture + Code testable Rétroaction: « design » simple? - Code couplé + Code réutilisable + Architecture émergeante Toutes approches
  44. © 2013 Elapse Technologies © 2013 Elapse Technologies Le mot

    de la fin… Questions? Poursuivre la discussion? Image de digitalart / FreeDigitalPhotos.net @fbourbonnais Félix-Antoine Bourbonnais fbourbonnais@elapsetech.com elapsetech.com/fab
  45. © 2013 Elapse Technologies © 2013 Elapse Technologies Téléchargement Image

    de anamkkml/ FreeDigitalPhotos.net et github.com Diapositives http://developpementagile.com/ architecture-mocks-tdd Code source https://github.com/fbourbonnais/ propulsez-architecture-tdd-mocks
  46. © 2013 Elapse Technologies © 2013 Elapse Technologies Elapse Technologies

    Formation Accompagnement (coaching) Conseils et diagnostiques Votre allié en développement logiciel Agile Agilité (Scrum, Lean, XP) Qualité et tests automatisés Architecture Agile Pratiques de développement
  47. © 2013 Elapse Technologies © 2013 Elapse Technologies Références

  48. © 2013 Elapse Technologies © 2013 Elapse Technologies 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. © 2013 Elapse Technologies © 2013 Elapse Technologies 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