© 2

01

2 Elap

se Techn

olo

gies

Propulsez votre architecture grâce aux mocks

Agile Tour 2012 Montréal

24 novembre 2012

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

o Réusinage et qualité (Clean Code)

o Agile Scrum

Concepteur de logiciels

o Pratiques de développement

o Java, Python, etc.

2

@fbourbonnais

linkedin.com/in/fbourbonnais

elapsetech.com/fab

www.elapsetech.com

fbourbonnais@elapsetech.com

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Réchauffement…

Quelles sont vos attentes?

Qui fait du TDD?

Qui utilise des Mocks?

3

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Comment découvrir l’architecture?

TDD

Mocks

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies DOUBLURES ET MOCKS

Introduction aux

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Tests unitaires But: tester les modules en isolation.

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Fonctionnement

7

CUTTest

CUT

A

B

X

N

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Fonctionnement

8

CUTTest

CUT

A

B

X

N

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Fonctionnement

9

CUTTest

CUT

A’

D’

A’’ A’’’

Retourne [1, 2, 3]

Lance IOException

Retourne [1]

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies TDD

Rappels des fondements du

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Cycle du TDD

Écrire un test qui échoue

Faire passer le

test Réusiner

11

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

3

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

TDD « CLASSIQUE » Le design et le

Image: posterize / FreeDigitalPhotos.net

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

TDD classique

Image: nuchylee / FreeDigitalPhotos.net

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

TDD classique Extraction des types

Classe P Classe

R1

PTest

Division

R1Test

Classe P

PTest

Mock R1

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies L’ORIENTATION OBJET

Rappel de

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Infrastructure Domaine UI

Messages et collaboration

Classe A

Collaboration des objets fonctionnalité

Classe B

Classe C

Classe E

Classe F

Classe D

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Le « Tell don’t Ask »

Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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 »

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Stim

ulu

s 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

Effe

t

Effe

t

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

PILOTER SON DESIGN AVEC DES MOCKS?

Comment

Image: jscreationzs / FreeDigitalPhotos.net

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

Viewer <<Interface>>

Loader Viewer

Test

Découverte pas à pas

Classe PNGLoader

PNGLoaderTest

<<Interface>>

FileReader

Mock Mock

?

?

Tirer les types à partir de la demande

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

TDD piloté par les Mocks Arriver à destination…

Test acceptation

Viewer

UTest

Terminé

<<Interface>>

Loader

Classe PNGLoader

Utest

<<Interface>>

FileReader

Fake FileReader

Utest

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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)

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies DÉMONSTRATION

Présentation de la

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Approche « top-down »

Image: Simon Howden / FreeDigitalPhotos.net

UI

Domaine

Infrastructure

Duplication?

Réusinage

TDD

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Piloter le design par les mocks

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

UI

Domaine

Infrastructure

MyLibraryView

…Presenter

OnlineLibrary Book

LibraryProvider

LibraryRealTimeView

…Presenter

OnlineService

Mock

Mock

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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 »

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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.

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

37

@fbourbonnais

Félix-Antoine Bourbonnais

fbourbonnais@elapsetech.com

elapsetech.com/fab

Image de digitalart / FreeDigitalPhotos.net

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Téléchargement

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

Diapositives http://developpementagile.com

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Elapse Technologies

Formation

Accompagnement (coaching)

Conseils et diagnostiques

Votre allié en développement logiciel Agile

Agilité (Scrum, Lean, XP)

Qualité et tests automatisés

Architecture Agile

Pratiques de développement

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

Références

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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

© 2

01

2 Elap

se Techn

olo

gies ©

20

12

Elapse Tech

no

logies

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