Propulser sa carrière grâce à LinkedIn et aux réseaux sociaux
Propulser votre architecture grâce aux mocks
-
Upload
elapse-technologies -
Category
Technology
-
view
2.246 -
download
0
description
Transcript of Propulser votre architecture grâce aux mocks
Propulsez votre architecture grâce aux mocks
Confoo 2012
Montréal, Québec, Canada
2 mars 2012
Félix-‐Antoine Bourbonnais Ing. jr, PSM-‐I
! Formateur et Coach Agile
! Enseignement et formaKons o TDD, Réusinage, OO avancé, AOP, tests, Scrum
! Recherches o AOP, agilité, tests et mocks
! Développeur o Java et Python (principalement)
2
@Uourbonnais
Réchauffement…
Quelles sont vos aXentes?
Qui fait du TDD?
Qui uKlise des Mocks?
3
Comment découvrir l’architecture?
TDD
Mocks
J’uKlise déjà des mocks!
Image: graur codrin / FreeDigitalPhotos.net
On va parler des mocks pour piloter la découverte du design!
TESTS IntroducKon aux
Plusieurs types de tests
Unitaire
Système
Bout-‐en-‐bout AcceptaKon
IntégraKon
…
Images: Renjith Krishnan, Salvatore Vuono, Jscreationzs, Photostock, Posterize / FreeDigitalPhotos.net
Tests unitaires But: tester les modules en isola*on.
DOUBLURES ET MOCKS IntroducKon aux
FoncKonnement
Module 3 : Tests unitaires Techniques et outils ! Mocks
FonctionnementSystème
(c) 2008-2009 F.-A. Bourbonnais et G.-E. Legendre, (c) 2010 F.-A. Bourbonnais. Contrôle de la qualité et métriques du logiciel GLO-4002 Automne 2010 39 / 60
10
FoncKonnement
Module 3 : Tests unitaires Techniques et outils ! Mocks
FonctionnementIsoler
(c) 2008-2009 F.-A. Bourbonnais et G.-E. Legendre, (c) 2010 F.-A. Bourbonnais. Contrôle de la qualité et métriques du logiciel GLO-4002 Automne 2010 40 / 60
11
FoncKonnement
Module 3 : Tests unitaires Techniques et outils ! Mocks
FonctionnementMocks
(c) 2008-2009 F.-A. Bourbonnais et G.-E. Legendre, (c) 2010 F.-A. Bourbonnais. Contrôle de la qualité et métriques du logiciel GLO-4002 Automne 2010 41 / 60
12
UKlisaKons
• Simuler un cas précis dans un objet uKlisé par l’objet testé.
• Exemple: Simuler une excepKon lancée.
Piloter (simuler un cas)
• Vérifier que l’objet testé a eu l’effet désiré sur un autre objet.
• Exemple: Vérifier que la méthode a été appelée sur un autre objet.
Vérifier un comportement
13
TDD IntroducKon au
Cycle du TDD
Écrire un test qui échoue
Faire passer le
test Réusiner
15
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
Pourquoi faire du TDD
16
La peur du changement…
Image: David CasKllo Dominici / FreeDigitalPhotos.net
Peur = î maintenabilité
Focaliser sur le « QUOI »
17
« Instead of just using tesKng to verify our work aker it’s done, TDD turns tesKng into a design ac*vity. [1] »
« We use the tests to clarify our ideas about what we want the code to do. [1]»
Se placer en posiKon d’uKlisateur du code
Se concentrer sur le « QUOI »
[1] Steve Freeman et Nat Pryce. Growing Object-‐Oriented So2ware, Guided by Tests. Addison-‐Wesley Professional, 1 ediKon, Octobre 2009.
TDD et architecture
! Favorise l’écriture de code testable ! Offre une rétroacKon concernant la facilité d’uKlisaKon du « design »
! Favorise l’écriture de code faiblement couplé
! Favorise l’écriture de code réuKlisable ! Favorise l’évoluKon de l’architecture et la découverte progressive o Colle à la réalité et aux besoins présents
L’ORIENTATION OBJET Rappel de
Infrastructure Domaine UI
Messages et collaboraKon
Classe A
Collabora*on des objets à fonc*onnalité
Classe B
Classe C
Classe E
Classe F
Classe D
Le « Tell don’t Ask »
Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net
Pourquoi le « Tell don’t ask »
! Cacher le « comment »
! Limiter l’effet des modificaKons à la logique (algorithme)
! Éviter les « trains » d’appels ! Réduire la duplicaKon ! Laisser les objets « s’occuper de leurs oignons » ! Éviter les « domaines anémiques »
SKmulus
Un objet est une boîte noire
Classe
RécepKon d’un message
Envoi d’un message à un collaborateur
Envoi d’un message à un collaborateur
Retour d’une réponse
Effet
Effet
TDD « CLASSIQUE » Le design et le
Image: posterize / FreeDigitalPhotos.net
TDD classique
Centré sur l’état et le résultat final.
Image: nuchylee / FreeDigitalPhotos.net
TDD classique ExtracKon des types
Classe P Classe
R1
PTest
Division
R1Test
Classe P
PTest
Mock R1
PILOTER SON DESIGN AVEC DES MOCKS?
Comment
Image: jscreationzs / FreeDigitalPhotos.net
TDD piloté par les Mocks Tirer à parKr des besoins
A
Tirer les types à parKr de la demande
B
C
Capacité de B et C (services) Besoins de A
TDD piloté par les Mocks IdenKfier les rôles requis (dépendances) par le module testé
Viewer <<Interface>> Loader
ViewerTest
Découverte pas à pas
Classe PNGLoader
PNGLoaderTest
<<Interface>> FileReader
Mock Mock
?
?
Tirer les types à parKr de la demande
TDD piloté par les Mocks Arriver à desKnaKon…
Test acceptaKon Viewer
UTest
Terminé
<<Interface>> Loader
Classe PNGLoader
Utest
<<Interface>> FileReader
Fake FileReader Utest
ÉvoluKon du design
Réusinage
• InteracKons • Signatures • …
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)
Avantages
! Favorise le respect du « Tell don’t ask » ! Permet de définir les interface à parKr des besoins
o Force à se concentrer sur le « Quoi » avant le « Comment »
o On définit d’abord le « Quoi » à parKr des tests des autres
! Retarde les décisions d’implémentaKons
! Favorise un design testable ! L’isolaKon favorise le réusinage
33
Ce que l’on obKent généralement
! Hiérarchie mince
! Design basé sur les rôles ! AbstracKon (sous la forme de rôles)
! Nommage en posiKon d’uKlisateur o Méthodes et types
! Meilleur respect du « Tell don’t ask »
! Parfois moins de temps en déverminage pour trouver le problème lorsqu’un test ne passe plus
Désavantages
! Ne permet pas d’établir le « comment »
! Peut résulter en une trop grande séparaKon o Trop de classes/interfaces
! FoncKonne moins bien sur les systèmes basés sur les données
35
Approche « top-‐down »
UI
Domaine
Infrastructure
Image: Simon Howden / FreeDigitalPhotos.net
DuplicaKon?
Réusinage
TDD
Piloter le design par les mocks
UI
Domaine
Infrastructure
Image: Simon Howden / FreeDigitalPhotos.net
MyLibraryView
…Presenter
OnlineLibrary Book
LibraryProvider
LibraryRealTimeView
…Presenter
OnlineService
Mock
Mock
! Composer à parKr des interacKons
! PosiKon « uKlisateur » ! ExploraKons successives
(étape par étape)
! Reporter les décisions d’implémentaKons
! Explorer sans trop se compromeXre
Favoriser la détecKon des mauvaises odeurs... ! 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 mulKples (constructeurs et méthodes) o ExtracKon d’un concept?
! Incapable de trouver un nom
! Etc.
DÉMONSTRATION PrésentaKon de la
Complémentarité
! CeXe 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)
40
Téléchargement
Image: rajcreationzs / FreeDigitalPhotos.ne 41
Téléchargez les diaposiKves complètes sur developpementagile.com
Évaluez la présentaKon sur: hXps://joind.in/6106
QUESTIONS Période de
42
Références
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 hXp://www.infoq.com/presentaKons/Mock-‐Objects-‐Nat-‐Pryce-‐Steve-‐Freeman
! MarKn Fowler, Mocks Aren’t Stubs, 2 janvier 2007. [Résumé des approches] hXp://marKnfowler.com/arKcles/mocksArentStubs.html
Références ! Steve Freeman, Sustainable Test-‐Driven Development. QCon San Francisco
2009. hXp://www.infoq.com/presentaKons/Sustainable-‐Test-‐Driven-‐Development
! Codemanship presents... Classic TDD vs. London School, 2011. [CriKqué] hXp://www.youtube.com/watch?v=AUE155LISV4
! Michael Feathers et Steve Freeman. Michael Feathers and Steve Freeman on Design, InfoQ at QCon San Francisco 2009 hXp://www.infoq.com/interviews/feathers-‐freeman-‐design
! Discussion – « Classic TDD or « London School » -‐ any opinions/comments/elaboraPon on Jason Gorman’s post? » GOOS Mailinglist, 2011. hXps://groups.google.com/d/topic/growing-‐object-‐oriented-‐sokware/dOmOIafFDcI/discussion