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