Propulsez votre architecture grâce au TDD et aux mocks (Agile Tour Montréal 2012)

Propulsez votre architecture
grâce aux mocks

Agile Tour 2012

© 2012 Elapse Technologies
Montréal

24 novembre 2012

Félix-Antoine Bourbonnais
Ing. jr, PSM-I

Formateur & Coach Agile
o Tests automatisés: TDD/ATDD, BDD, …
o Orientation objet avancée
o Architecture agile

www.elapsetech.com
o Réusinage et qualité (Clean Code)
fbourbonnais@elapsetech.com
o Agile Scrum

elapsetech.com/fab
Concepteur de logiciels
@fbourbonnais
o Pratiques de développement
linkedin.com/in/fbourbonnais
o Java, Python, etc.

2

Réchauffement…
Quelles sont vos
attentes?

Qui fait du TDD?

Qui utilise des Mocks?

3

Comment découvrir l’architecture?

TDD
Mocks

DOUBLURES ET MOCKS
Introduction aux

Tests unitaires
But: tester les modules en isolation.


7
N
X
A

B
Fonctionnement

CUT
CUT
Test

8
N
X
A

B
Fonctionnement

CUT
CUT
Test

Fonctionnement

A’ A’’ A’’’

Retourne Lance Retourne

[1] IOException [1, 2, 3]
CUT
CUT
Test

D’

9

Rappels des fondements du

TDD

Cycle du TDD

Écrire un 1
On passe à la phase
test qui « VERTE » dès qu’on a un
échoue test qui échoue.

Erreur de compilateur
= « échec ».

Faire
3 Réusiner passer le
test
2
On passe à la phase « Réusinage »
dès que le test passe.
11

Le design et le

TDD « CLASSIQUE »

Image: posterize / FreeDigitalPhotos.net

TDD classique

Centré sur l’état et le résultat final

Image: nuchylee / FreeDigitalPhotos.net

TDD classique
Extraction des types

Classe Division
P Classe Classe

P R1
Mock
R1

PTest PTest R1Test

Le TDD classique
Centré sur la logique
Évolution du « design »
o Par division

o Découverte des types par extraction
Avantages – « Détails et logique»
o Construit des composants très modulaires et faiblement
couplés
o Facilite la réutilisation

15

L’ORIENTATION OBJET
Rappel de

Messages et collaboration

Classe
C
Classe
B

Classe
Classe D
A
Classe Classe
E F

UI Domaine Infrastructure
Collaboration des objets  fonctionnalité

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 modifications à la logique
(algorithme)

Éviter les « trains » d’appels
Réduire la duplication
Laisser les objets « s’occuper de leurs oignons »
Éviter les « domaines anémiques »

Un objet est une boîte noire
Stimulus

Réception d’un message

Envoi d’un message à

un collaborateur

Effet
Classe
Envoi d’un message à
un collaborateur
Effet

Retour d’une réponse

Comment

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

Le TDD « Mockiste »
Centré sur les
o Interactions entre les objets
o Rôles et responsabilités

Utilise les Mocks comme pierre angulaire
Évolution du « design »
o Par le raffinement
o Découverte des types par les Mocks
o Définition de l’interface à partir des besoins établis dans
les autres tests grâce aux mocks.

22

TDD piloté par les Mocks
Identifier les rôles requis (dépendances) par le module testé

Viewer <<Interface>> <<Interface>>
Test
Viewer ? Loader FileReader

Mock
Mock
PNGLoader Classe
Test ?
PNGLoader

Découverte pas à pas

Tirer les types à partir de la demande

TDD piloté par les Mocks
Arriver à destination…

Test <<Interface>> <<Interface>>
acceptation
Viewer Loader FileReader

UTest

Utest
Classe Fake
Utest
PNGLoader FileReader

Terminé

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)

DÉMONSTRATION
Présentation de la

Soumissions à une conférence
Système pour gérer les propositions soumises à une
conférence
Story #1:

o Permettre la soumission d’une présentation
o Les présentations doivent être accumulées en attendant
d’être évaluées par le comité
o Notifier le comité à la réception

Approche « top-down »

UI

Réusinage

Domaine

Infrastructure TDD

Duplication?

Image: Simon Howden / FreeDigitalPhotos.net

Piloter le design par les mocks
MyLibraryView
LibraryRealTime Composer à partir des
View
interactions
…Presenter …Presenter
UI
Position « utilisateur »
Moc

k
OnlineLibrary Book Explorations successives
Moc
(étape par étape)
LibraryProvider k
Reporter les décisions
Domaine
d’implémentations
OnlineService
Explorer sans trop se
compromettre
Infrastructure

Image: Simon Howden / FreeDigitalPhotos.net

Avantages
Favorise le respect du « Tell don’t ask »
Permet de définir les interfaces à partir des besoins
o Force à se concentrer sur le « Quoi » avant le « Comment »

o On définit d’abord le « Quoi » à partir des tests des autres
Retarde les décisions d’implémentations
Favorise un design testable
L’isolation favorise le réusinage

31

Ce que l’on obtient généralement
Hiérarchie mince
Design basé sur les rôles
Abstraction (sous la forme de rôles)

Nommage en position d’utilisateur
o Méthodes et types
Meilleur respect du « Tell don’t ask »

Désavantages
Moins adapté pour découvrir les détails
(le « comment »)
Peut résulter en une trop grande séparation

o Trop de classes/interfaces
Fonctionne moins bien sur les systèmes basés sur les
données et fortement algorithmiques

33

Mauvaises odeurs détectables
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 multiples (constructeurs et méthodes)
o Extraction d’un concept?
Incapable de trouver un nom
Etc.

Complémentarité
Cette 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)

35

TDD et architecture
Favorise l’écriture de code testable
Offre une rétroaction concernant la facilité
d’utilisation du « design »

Favorise l’écriture de code faiblement couplé
Favorise l’écriture de code réutilisable
Favorise l’évolution de l’architecture et la découverte
progressive
o Colle à la réalité et aux besoins présents

Le mot de la fin…
Questions? Poursuivre la discussion?

Félix-Antoine Bourbonnais

@fbourbonnais

fbourbonnais@elapsetech.com
elapsetech.com/fab

Image de digitalart / FreeDigitalPhotos.net 37

Téléchargement

Diapositives
http://developpementagile.com

Code
https://github.com/fbourbonnais/
elapse-mocks-architecture-atmtl2012

Image de anamkkml/ FreeDigitalPhotos.net et github.com 38

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

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

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

Propulsez votre architecture grâce au TDD et aux mocks (Agile Tour Montréal 2012)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Propulsez votre architecture grâce au TDD et aux mocks (Agile Tour Montréal 2012)

Ähnlich wie Propulsez votre architecture grâce au TDD et aux mocks (Agile Tour Montréal 2012) (20)

Propulsez votre architecture grâce au TDD et aux mocks (Agile Tour Montréal 2012)