Propulsez votre architectures grâce au TDD et aux Mocks (Agile Montréal 2014)

Nous savons depuis longtemps que les tests automatisés jouent un rôle important pour les équipes de développement Agile. Les grands ténors du TDD ont depuis longtemps identifié des gains en rapport avec le design (conception architecturale).

Bien qu’il soit rare que l’on aborde et explique la façon d’obtenir ce bénéfice, la communauté a découvert avec le temps certaines pratiques et techniques permettant de maximiser l’émergence du design via le TDD.

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 » ou parfois appelée « école de Londres ».

Ainsi, nous verrons comment les mocks peuvent nous aider à concevoir une architecture ayant une meilleure conception orientée objet. On y présentera également certaines astuces servant à faire ressortir l’essentiel de ses propres tests.

La séance prendra la forme d’un tutoriel (démonstration) en réalisant pas à pas un design simple parsemé de trucs et astuces.

Transcript

1. 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
   

   View Slide

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

   View Slide

3. Félix-Antoine Bourbonnais
   Ing. jr, PSM, M.Sc.
   www.elapsetech.com
   Formation – Accompagnement – Conseils
   fbourbonnais@elapsetech.com
   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
   

   View Slide

4. © 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…
   

   View Slide

5. © 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
   

   View Slide

6. © 2014 Elapse Technologies
   DOUBLURES ET MOCKS
   Rappel sur les
   

   View Slide

7. © 2014 Elapse Technologies
   Rappel: les tests unitaires
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. © 2014 Elapse Technologies
    TDD
    Rappels des fondements du
    

    View Slide

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

    View Slide

13. © 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
    

    View Slide

14. © 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. © 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
    

    View Slide

19. © 2014 Elapse Technologies
    L’ORIENTATION OBJET
    Rappel de
    

    View Slide

20. © 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
    

    View Slide

21. © 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 !?!
    

    View Slide

22. © 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 »
    

    View Slide

23. © 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
    …
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. © 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
    

    View Slide

28. © 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
    

    View Slide

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

    View Slide

30. © 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
    

    View Slide

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

    View Slide

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

    View Slide

33. © 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
    

    View Slide

34. © 2014 Elapse Technologies
    CONCLUSION et RÉSUMÉ
    

    View Slide

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

    View Slide

36. © 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
    

    View Slide

37. © 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
    

    View Slide

38. © 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 »
    

    View Slide

39. © 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
    

    View Slide

40. © 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)
    

    View Slide

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

    View Slide

42. © 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
    

    View Slide

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

    View Slide

44. © 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
    

    View Slide

45. © 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
    

    View Slide

46. © 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
    

    View Slide

47. © 2014 Elapse Technologies
    Références
    

    View Slide

48. © 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
    

    View Slide

49. © 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
    

    View Slide