Propulsez votre architecture grâce au TDD et aux mocks

Transcription

1 nasa.gov Propulsez votre architecture grâce au TDD et aux mocks Agile Québec 12 juin Elapse Technologies

2 Avertissement Cette présentation est de niveau «avancé»

3 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@elapsetech.com linkedin.com/in/fbourbonnais/fr

4 Réchauffement Qui fait du TDD? Qui utilise des Mocks? Quelles sont vos attentes? Images de: Idea Go / freedigitalphotos.net Rameshng / Flickr.com

5 Comment découvrir l architecture? Mocks TDD

6 Rappel sur les DOUBLURES ET MOCKS

7 Rappel: les tests unitaires But: tester les modules en isolation.

8 Rappel: les mocks A X CUT Test CUT B N

9 Rappel: les mocks A X C Test C B N

10 Rappel: les mocks A A C Test C Retourne [1] B Lance IOException

11 Rappels des fondements du TDD

12 Technique ou discipline? Le TDD est une discipline

13 Cycle du TDD Écrire un test qui échoue 1 On passe à la phase «VERTE» dès qu on a un test qui échoue. 3 Réusiner Faire passer le test Erreur de compilateur = «échec». 2 On passe à la phase «Réusinage» dès que le test passe.

14 Shu-Ha-Ri SHU HA RI L élève suit l enseignement d un maître Il apprend de d autres maîtres (écoles) Il suit et a sa propre pratique Power de Jardson Araújo du The Noun Project Keikogi de Tiago Dos Reis Rodrigues duthe Noun Project

15 Le design et le TDD «CLASSIQUE» Image: posterize / FreeDigitalPhotos.net

16 TDD classique Centré sur l état et le résultat final Image: nuchylee / FreeDigitalPhotos.net

17 TDD classique Extraction des types Classe P PTest Division Classe P PTest Mock R1 Classe R1 R1Test

18 Le TDD classique Problèmes algorithmiques Évolution du «design» Par division Extraction Traitement de données Calculs TDD Classique Valide l état

19 Rappel de L ORIENTATION OBJET

20 Messages et collaboration Classe ACtrl Classe B Classe C Iface E Classe D Classe Persist UI Domaine Infrastructure Collaboration des objets fonctionnalité

21 Le «Tell don t Ask» Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net

22 Pourquoi le «Tell don t ask» Cacher le «comment» Réduire la duplication Limiter l effet des modifications Laisser les objets «s occuper de leurs oignons» Limiter l effet d avalanche Éviter les «domaines anémiques»

23 Effet Effet Stimulus Un objet est une boîte noire Réception d un message Retour d une réponse Classe Envoi d un message à un collaborateur Envoi d un message à un collaborateur

24 Comment PILOTER SON DESIGN AVEC DES MOCKS? Image: jscreationzs / FreeDigitalPhotos.net

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

26 Le TDD «Mockiste» Utilise les Mocks comme pierre angulaire Images: cooldesign/ freedigitalphotos.net

27 Évolution du «design» TDD «Mockiste» 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.

28 TDD piloté par les Mocks Identifier les rôles requis (dépendances) par le module testé Viewer Test Viewer <<Interface>>? Loader <<Interface>> FileReader PNGLoader Test Mock Classe PNGLoader? Mock Découverte pas à pas Tirer les types à partir de la demande

29 TDD piloté par les Mocks Arriver à destination Test acceptation UTest Viewer Utest <<Interface>> Loader Classe PNGLoader Utest <<Interface>> FileReader Fake FileReader Terminé

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

31 Exemple banque.acheter(carte, marchand, montant) --> carte.crediter(montant) --> marchand.debiter(montant)

32 Présentation de la DÉMONSTRATION Image: Stuart Miles / freedigitalphotos.net

33 Soumissions à une conférence Démonstration #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

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

35 Piloter le design par les mocks MyLibraryView Presenter Moc k OnlineLibrary LibraryProvider OnlineService UI Moc k Domaine Infrastructure LibraryRealTime View Presenter Book 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

36 Avantages de l approche mockiste Favorise le «Tell don t ask» Favorise un design testable Moins de «trains d appels» (Demeter) Requiert moins d objets implémentés pour avoir une rétroaction Retarde les décisions d implémentations Classe fautive ciblée en cas d échec

37 Avantages de l approche mockiste Définir les interfaces à partir des appelants Développement piloté par les besoins (need-driven) Focalise sur le «Quoi» avant le «Comment»

38 Ce que l on obtient généralement Hiérarchie mince Nommage clair pour l appelant Design basé sur les rôles Meilleur respect des principes OO Abstraction (rôles)

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

40 La Bonne question Que voulez-vous maximiser?

41 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 Mauvaises odeurs détectables Mauvaise odeurs avec les mocks Beaucoup de Mocks Difficile de les injecter Beaucoup de paramètres Couplage OCP? Patron «Factory»? Extraction d un concept?

43 Rappel: TDD et architecture Toutes approches + Code testable + Code réutilisable Rétroaction: «design» simple? + Architecture émergeante - Code couplé

44 Le mot de la fin Questions? Poursuivre la discussion? Félix-Antoine elapsetech.com/fab Image de digitalart / FreeDigitalPhotos.net

45 Téléchargement Diapositives architecture-mocks-tdd Code source propulsez-architecture-tdd-mocks Image de anamkkml/ FreeDigitalPhotos.net et github.com

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

47 Références

48 Références Steve Freeman, Tim Mackinnon, Nat Pryce, et Joe Walnes. Mock roles, Not objects. p OOPSLA 04. Vancouver, BC, Canada, ACM, Nat Pryce, et Steve Freeman, InfoQ: Mock Roles Not Object States. QCon London Steve-Freeman Martin Fowler, Mocks Aren t Stubs, 2 janvier [Résumé des approches]

49 Références Steve Freeman, Sustainable Test-Driven Development. QCon San Francisco Development Codemanship presents... Classic TDD vs. London School, [Critiqué] Michael Feathers et Steve Freeman. Michael Feathers and Steve Freeman on Design, InfoQ at QCon San Francisco Discussion «Classic TDD or «London School» - any opinions/comments/elaboration on Jason Gorman s post?» GOOS Mailinglist,