Slide 1

Slide 1 text

Propulsez votre architecture grâce au TDD et aux Mocks FÉLIX-ANTOINE BOURBONNAIS ING.JR, PSM, M.SC. Agile Montréal 12 mars 2014 nasa.gov

Slide 2

Slide 2 text

© 2014 Elapse Technologies Image de Eyesplash http://commons.wikimedia.org/wiki/File:Welkom_willkommen_Welcome_Bienvenue_Benvenuto.jpg

Slide 3

Slide 3 text

Félix-Antoine Bourbonnais Ing. jr, PSM, M.Sc. www.elapsetech.com Formation – Accompagnement – Conseils [email protected] elapsetech.com/fab @fbourbonnais linkedin.com/in/fbourbonnais Contact Formateur et Coach Agile Tests automatisés TDD BDD et ATDD Code propre Qualité logicielle Architecture Agile Orientation objet Orientation aspect Design testable et émergeant Scrum Accompagnement d’équipes Agent de changement

Slide 4

Slide 4 text

© 2014 Elapse Technologies Avertissement Cette présentation s’adresse principalement à un public ayant déjà expérimenté le TDD mais aucune supervision n’est nécessaire pour en profiter…

Slide 5

Slide 5 text

© 2014 Elapse Technologies Réchauffement… Qui fait du TDD? Qui utilise des Mocks? Quelles sont vos attentes? Images de Idea Go / freedigitalphotos.net et ameshng / Flickr.com

Slide 6

Slide 6 text

© 2014 Elapse Technologies DOUBLURES ET MOCKS Rappel sur les

Slide 7

Slide 7 text

© 2014 Elapse Technologies Rappel: les tests unitaires

Slide 8

Slide 8 text

© 2014 Elapse Technologies Rappel: les Mocks CUT Test CUT A B X N

Slide 9

Slide 9 text

© 2014 Elapse Technologies Rappel: les mocks C Test C A B X N

Slide 10

Slide 10 text

© 2014 Elapse Technologies Rappel: les mocks C Test C A’ B’ A’’ Lance IOException Retourne [1]

Slide 11

Slide 11 text

© 2014 Elapse Technologies TDD Rappels des fondements du

Slide 12

Slide 12 text

© 2014 Elapse Technologies Technique ou discipline? Le TDD est une discipline

Slide 13

Slide 13 text

© 2014 Elapse Technologies Rappel: Le 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 1

Slide 14

Slide 14 text

© 2014 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

Slide 15

Slide 15 text

© 2014 Elapse Technologies TDD « CLASSIQUE » Le design et le Image: posterize / FreeDigitalPhotos.net

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

© 2014 Elapse Technologies TDD classique Extraction des types Classe P Classe R1 PTest Division R1Test Classe P PTest Mock R1

Slide 18

Slide 18 text

© 2014 Elapse Technologies TDD classique En résumé TDD Classique Évolution du « design » •Par division •Extraction Problèmes algorithmiques •Traitement de données •Calculs Valide l’état

Slide 19

Slide 19 text

© 2014 Elapse Technologies L’ORIENTATION OBJET Rappel de

Slide 20

Slide 20 text

© 2014 Elapse Technologies Infrastructure Domaine UI Messages et collaboration Classe ACtrl Collaboration des objets  fonctionnalité Classe B Classe C Iface E Classe Persist Classe D

Slide 21

Slide 21 text

© 2014 Elapse Technologies Le « Tell don’t Ask » getAmi(joe) .getCorps() .getJambe(Orient.GAUCHE) .setPosition( sol + 5, centre + 20) Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net Hein !?!

Slide 22

Slide 22 text

© 2014 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 »

Slide 23

Slide 23 text

© 2014 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 …

Slide 24

Slide 24 text

© 2014 Elapse Technologies PILOTER SON DESIGN AVEC DES MOCKS? Comment Image: jscreationzs / FreeDigitalPhotos.net

Slide 25

Slide 25 text

© 2014 Elapse Technologies Le TDD « Mockiste » Centré sur les interactions et comportements entre les objets considérant leur rôle

Slide 26

Slide 26 text

© 2014 Elapse Technologies Le TDD « Mockiste » Utilise les Mocks comme pierre angulaire Images: cooldesign/ freedigitalphotos.net

Slide 27

Slide 27 text

© 2014 Elapse Technologies TDD « Mockiste » Extraction des types Découverte des types par les Mocks Définition de l’interface à partir des besoins établis dans les autres tests

Slide 28

Slide 28 text

© 2014 Elapse Technologies TDD piloté par les Mocks Identifier les rôles Viewer <> Loader Viewer Test Découverte pas à pas Classe PNGLoader PNGLoader Test <> FileReader Mock Mock ? ? Tirer les types à partir de la demande

Slide 29

Slide 29 text

© 2014 Elapse Technologies TDD piloté par les Mocks Arriver à destination… Test acceptation Viewer UTest Terminé <> Loader Classe PNGLoader Utest <> FileReader Fake FileReader Utest

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

© 2014 Elapse Technologies Exemple banque.acheter(carte, marchand, montant) --> carte.crediter(montant) --> marchand.debiter(montant)

Slide 32

Slide 32 text

© 2014 Elapse Technologies DÉMONSTRATION Présentation de la Image: Stuart Miles / freedigitalphotos.net

Slide 33

Slide 33 text

© 2014 Elapse Technologies Démonstration 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

Slide 34

Slide 34 text

© 2014 Elapse Technologies CONCLUSION et RÉSUMÉ

Slide 35

Slide 35 text

© 2014 Elapse Technologies Approche « outside-in » Image: Simon Howden / FreeDigitalPhotos.net UI Domaine Infrastructure Duplication? Réusinage TDD

Slide 36

Slide 36 text

© 2014 Elapse Technologies Piloter le design par les mocks Image: Simon Howden / FreeDigitalPhotos.net UI Domaine Infrastructure MyLibraryView …Presenter OnlineLibrary Book LibraryProvider LibraryRealTime View …Presenter OnlineService Moc k Moc k Composer à partir des interactions Position « utilisateur » Explorations successives (étape par étape) Reporter les décisions d’implémentations Explorer sans trop se compromettre

Slide 37

Slide 37 text

© 2014 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

Slide 38

Slide 38 text

© 2014 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 »

Slide 39

Slide 39 text

© 2014 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 Possible meilleur respect des principes OO

Slide 40

Slide 40 text

© 2014 Elapse Technologies Désavantages de l’approche mockiste Couplage du test avec la signature des collaborateurs Fragiliser les tests Fonctionne mal avec des problèmes algorithmiques Peut générer beaucoup de Mocks et d’interfaces Manquer de tests intégrés (pyramide)

Slide 41

Slide 41 text

© 2014 Elapse Technologies La bonne question… Que voulez-vous maximiser ?

Slide 42

Slide 42 text

© 2014 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

Slide 43

Slide 43 text

© 2014 Elapse Technologies Rappel: TDD et architecture + Code testable + de « design » simple? - de code couplé + de code réutilisable + d’architecture émergeante

Slide 44

Slide 44 text

© 2014 Elapse Technologies Pour aller plus loin… Image de anamkkml/ FreeDigitalPhotos.net et github.com Code source https://github.com/fbourbonn ais/propulsez-architecture-tdd- mocks Diapositives http://developpementagile.com/ar chitecture-mocks-tdd Les tests en agilités TDD pour gestionnaires Introduction à l’ATDD et BDD TDD avancé TDD Concepts OO avancés Nos formations sur le sujet www.elapsetech.com/formation

Slide 45

Slide 45 text

© 2014 Elapse Technologies Merci Mon nom Félix-Antoine Bourbonnais Notre blogue developpementagile.com Notre site elapsetech.com Mon Twitter @fbourbonnais Mon LinkedIn linkedin.com/in/fbourbonnais/fr

Slide 46

Slide 46 text

© 2014 Elapse Technologies Elapse Technologies Formation Accompagnement (coaching) Mentorat virtuel Conseils et diagnostics Agilité (Scrum, Lean, XP) Qualité et tests automatisés Architecture Agile Pratiques de développement Votre allié en développement logiciel Agile

Slide 47

Slide 47 text

© 2014 Elapse Technologies Références

Slide 48

Slide 48 text

© 2014 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

Slide 49

Slide 49 text

© 2014 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