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

Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Montréal 2012)

Propulsez votre architecture grâce au TDD et aux Mocks (Agile Tour Montréal 2012)

Présentée à Agile Tour Montréal 2012 (Agile Montréal) le 24 novembre 2012.

Nous savons depuis longtemps que les tests automatisés jouent un rôle important pour les équipes de développement Agile. Bien que la communauté ait découvert depuis un certain temps des pratiques permettant de maximiser l’émergence du design via le TDD, il est rare que l’on présente des astuces concrètes pour obtenir ce bénéfice.

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 ». Ainsi, nous verrons comment les mocks peuvent nous aider à concevoir une architecture ayant une meilleure conception orientée objet.

La séance prendra la forme d'un tutoriel (démonstration).

Niveau : Avancé
Public cible : Développeurs et architectes
Version de 90 minutes

F209924610808dc55f985a99c6d380c3?s=128

Félix-Antoine Bourbonnais

November 24, 2012
Tweet

Transcript

  1. © 2012 Elapse Technologies Propulsez votre architecture grâce aux mocks

    Agile Tour 2012 Montréal 24 novembre 2012
  2. © 2012 Elapse Technologies © 2012 Elapse Technologies Félix-Antoine Bourbonnais

    Ing. jr, PSM-I 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 Scrum Concepteur de logiciels o Pratiques de développement o Java, Python, etc. 2 @fbourbonnais linkedin.com/in/fbourbonnais elapsetech.com/fab www.elapsetech.com fbourbonnais@elapsetech.com
  3. © 2012 Elapse Technologies © 2012 Elapse Technologies Réchauffement… Quelles

    sont vos attentes? Qui fait du TDD? Qui utilise des Mocks? 3
  4. © 2012 Elapse Technologies © 2012 Elapse Technologies Comment découvrir

    l’architecture? TDD Mocks
  5. © 2012 Elapse Technologies © 2012 Elapse Technologies DOUBLURES ET

    MOCKS Introduction aux
  6. © 2012 Elapse Technologies © 2012 Elapse Technologies Tests unitaires

    But: tester les modules en isolation.
  7. © 2012 Elapse Technologies © 2012 Elapse Technologies Fonctionnement 7

    CUT Test CUT A B X N
  8. © 2012 Elapse Technologies © 2012 Elapse Technologies Fonctionnement 8

    CUT Test CUT A B X N
  9. © 2012 Elapse Technologies © 2012 Elapse Technologies Fonctionnement 9

    CUT Test CUT A’ D’ A’’ A’’’ Retourne [1, 2, 3] Lance IOException Retourne [1]
  10. © 2012 Elapse Technologies © 2012 Elapse Technologies TDD Rappels

    des fondements du
  11. © 2012 Elapse Technologies © 2012 Elapse Technologies Cycle du

    TDD Écrire un test qui échoue Faire passer le test Réusiner 11 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
  12. © 2012 Elapse Technologies © 2012 Elapse Technologies TDD «

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

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

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

    classique Centré sur la logique Évolution du « design » o Par division o Découverte des types par extraction Avantages – « Détails et logique» o Construit des composants très modulaires et faiblement couplés o Facilite la réutilisation 15
  16. © 2012 Elapse Technologies © 2012 Elapse Technologies L’ORIENTATION OBJET

    Rappel de
  17. © 2012 Elapse Technologies © 2012 Elapse Technologies Infrastructure Domaine

    UI Messages et collaboration Classe A Collaboration des objets  fonctionnalité Classe B Classe C Classe E Classe F Classe D
  18. © 2012 Elapse Technologies © 2012 Elapse Technologies Le «

    Tell don’t Ask » Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
  19. © 2012 Elapse Technologies © 2012 Elapse Technologies Pourquoi le

    « Tell don’t ask » Cacher le « comment » Limiter l’effet des modifications à la logique (algorithme) Éviter les « trains » d’appels Réduire la duplication Laisser les objets « s’occuper de leurs oignons » Éviter les « domaines anémiques »
  20. © 2012 Elapse Technologies © 2012 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
  21. © 2012 Elapse Technologies © 2012 Elapse Technologies PILOTER SON

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

    « Mockiste » Centré sur les o Interactions entre les objets o Rôles et responsabilités Utilise les Mocks comme pierre angulaire Évolution du « design » o Par le raffinement o Découverte des types par les Mocks o Définition de l’interface à partir des besoins établis dans les autres tests grâce aux mocks. 22
  23. © 2012 Elapse Technologies © 2012 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
  24. © 2012 Elapse Technologies © 2012 Elapse Technologies TDD piloté

    par les Mocks Arriver à destination… Test acceptation Viewer UTest Terminé <<Interface>> Loader Classe PNGLoader Utest <<Interface>> FileReader Fake FileReader Utest
  25. © 2012 Elapse Technologies © 2012 Elapse Technologies 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)
  26. © 2012 Elapse Technologies © 2012 Elapse Technologies DÉMONSTRATION Présentation

    de la
  27. © 2012 Elapse Technologies © 2012 Elapse Technologies Soumissions à

    une conférence Système pour gérer les propositions soumises à une conférence Story #1: o Permettre la soumission d’une présentation o Les présentations doivent être accumulées en attendant d’être évaluées par le comité o Notifier le comité à la réception
  28. © 2012 Elapse Technologies © 2012 Elapse Technologies Approche «

    top-down » Image: Simon Howden / FreeDigitalPhotos.net UI Domaine Infrastructure Duplication? Réusinage TDD
  29. © 2012 Elapse Technologies © 2012 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
  30. © 2012 Elapse Technologies © 2012 Elapse Technologies Avantages Favorise

    le respect du « Tell don’t ask » Permet de définir les interfaces à partir des besoins o Force à se concentrer sur le « Quoi » avant le « Comment » o On définit d’abord le « Quoi » à partir des tests des autres Retarde les décisions d’implémentations Favorise un design testable L’isolation favorise le réusinage 31
  31. © 2012 Elapse Technologies © 2012 Elapse Technologies Ce que

    l’on obtient généralement Hiérarchie mince Design basé sur les rôles Abstraction (sous la forme de rôles) Nommage en position d’utilisateur o Méthodes et types Meilleur respect du « Tell don’t ask »
  32. © 2012 Elapse Technologies © 2012 Elapse Technologies Désavantages Moins

    adapté pour découvrir les détails (le « comment ») Peut résulter en une trop grande séparation o Trop de classes/interfaces Fonctionne moins bien sur les systèmes basés sur les données et fortement algorithmiques 33
  33. © 2012 Elapse Technologies © 2012 Elapse Technologies Mauvaises odeurs

    détectables 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 multiples (constructeurs et méthodes) o Extraction d’un concept? Incapable de trouver un nom Etc.
  34. © 2012 Elapse Technologies © 2012 Elapse Technologies Complémentarité Cette

    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) 35
  35. © 2012 Elapse Technologies © 2012 Elapse Technologies TDD et

    architecture Favorise l’écriture de code testable Offre une rétroaction concernant la facilité d’utilisation du « design » Favorise l’écriture de code faiblement couplé Favorise l’écriture de code réutilisable Favorise l’évolution de l’architecture et la découverte progressive o Colle à la réalité et aux besoins présents
  36. © 2012 Elapse Technologies © 2012 Elapse Technologies Le mot

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

    de anamkkml/ FreeDigitalPhotos.net et github.com 38 Diapositives http://developpementagile.com Code https://github.com/fbourbonnais/ elapse-mocks-architecture-atmtl2012
  38. © 2012 Elapse Technologies © 2012 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
  39. © 2012 Elapse Technologies © 2012 Elapse Technologies Références

  40. © 2012 Elapse Technologies © 2012 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
  41. © 2012 Elapse Technologies © 2012 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