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

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