© 2

01

2 Elap

se Techn

olo

gies

© 2013 Elapse Technologies© 2013 Elapse Technologies

Propulsez votre architecture grâce au

TDD et aux mocks

Agile Québec

12 juin 2013

nas

a.go

v

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Avertissement

Cette présentation est de niveau « avancé »

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

linkedin.com/in/fbourbonnais/fr

elapsetech.com/fab

www.elapsetech.com

fbourbonnais@elapsetech.com

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Réchauffement…

Qui fait du TDD?

Qui utilise des Mocks?

Quelles sont vos attentes?

Images de: Idea Go / freedigitalphotos.net

Rameshng / Flickr.com

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Comment découvrir l’architecture?

TDD

Mocks

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

DOUBLURES ET MOCKSRappel sur les

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Rappel: les tests unitairesBut: tester les modules en isolation.

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Rappel: les mocks

CUTTest

CUT

A

B

X

N

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Rappel: les mocks

CTest

C

A

B

X

N

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Rappel: les mocks

CTest

C

A’

B’

A’’

LanceIOException

Retourne[1]

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

TDDRappels des fondements du

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Technique ou discipline?

Le TDD est une discipline

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Cycle du TDD

Écrire un test qui échoue

Faire passer le

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

3

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

TDD « CLASSIQUE »Le design et le

Image: posterize / FreeDigitalPhotos.net

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

TDD classique

Image: nuchylee / FreeDigitalPhotos.net

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

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

TDD classiqueExtraction des types

ClasseP Classe

R1

PTest

Division

R1Test

ClasseP

PTest

MockR1

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Le TDD classique

TDD Classique

Évolution du « design »

•Par division

•Extraction

Problèmes algorithmiques

•Traitement de données

•Calculs

Valide l’état

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

L’ORIENTATION OBJETRappel de

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

InfrastructureDomaineUI

Messages et collaboration

ClasseACtrl

Collaboration des objets fonctionnalité

ClasseB

ClasseC

IfaceE

ClassePersist

ClasseD

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Le « Tell don’t Ask »

Image: renjith krishnan et jscreationzs / FreeDigitalPhotos.net

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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 »

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Stim

ulu

sUn 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

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

PILOTER SON DESIGN AVEC DES MOCKS?

Comment

Image: jscreationzs / FreeDigitalPhotos.net

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Le TDD « Mockiste »

Centré sur les interactions et comportementsentre les objets considérant leur rôle

Images: sheelamohan / freedigitalphotos.net

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Le TDD « Mockiste »

Utilise les Mocks comme pierre angulaire

Images: cooldesign/ freedigitalphotos.net

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Évolution du « design »

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.

TDD « Mockiste »

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

Viewer<<Interface>>

LoaderViewer

Test

Découverte pas à pas

ClassePNGLoader

PNGLoaderTest

<<Interface>>

FileReader

MockMock

?

?

Tirer les types à partir de la demande

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

TDD piloté par les MocksArriver à destination…

Testacceptation

Viewer

UTest

Terminé

<<Interface>>

Loader

ClassePNGLoader

Utest

<<Interface>>

FileReader

FakeFileReader

Utest

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

En résumé

Quels effets aura ce comportement sur l’environnement immédiat?

De quoi est-ce que l’objet a besoin pour réaliser son travail en terme de

rôles ?

Quelle est la responsabilité de l’objet testé ?

Classe testée(CUT)

A

Besoin de(rôle)

B

Effet sur

Responsabilité

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Exemple

banque.acheter(carte, marchand, montant)

--> carte.crediter(montant)

--> marchand.debiter(montant)

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

DÉMONSTRATIONPrésentation de la

Image: Stuart Miles / freedigitalphotos.net

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Soumissions à une conférence

#1 Soumission d’une présentation

En tant que soumissionnaireJe veux soumettre une présentation à une conférenceAfin 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

Démonstration

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Approche « outside-in »

Image: Simon Howden / FreeDigitalPhotos.net

UI

Domaine

Infrastructure

Duplication?

Réusinage

TDD

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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 »

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

Meilleur respect des

principes OO

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Désavantages de l’approche mockiste

Couplage du test avec la signature

des collaborateurs

Fonctionne mal avec des

problèmes algorithmiques

Génère beaucoup de mocks et d’interfaces

Danger: Trop focaliser sur le UI

(outside-in)

Tests unitaires =>

aucun test intégré de bas niveau.

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

La Bonne question…

Que voulez-vous maximiser ?

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Mauvaises odeurs détectables

Mauvaise odeurs avec les mocks

Beaucoup de Mocks

Couplage…

Difficile de les injecter

OCP ?Patron

« Factory »?

Beaucoup de

paramètres

Extraction d’un

concept?

…

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Rappel: TDD et architecture

+ Code testable

Rétroaction:« design »

simple?

-Code couplé

+ Code réutilisable

+ Architecture émergeante

Toutes approches

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

Image de digitalart / FreeDigitalPhotos.net

@fbourbonnais

Félix-Antoine Bourbonnais

fbourbonnais@elapsetech.com

elapsetech.com/fab

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Téléchargement

Image de anamkkml/ FreeDigitalPhotos.net et github.com

Diapositiveshttp://developpementagile.com/

architecture-mocks-tdd

Code sourcehttps://github.com/fbourbonnais/

propulsez-architecture-tdd-mocks

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

Références

© 2

01

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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 2007http://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

3 Elap

se Te

chn

olo

gies

© 2

01

3 Elap

se Te

chn

olo

gies

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 2009http://www.infoq.com/interviews/feathers-freeman-design

Discussion – « Classic TDD or « London School » - anyopinions/comments/elaboration on Jason Gorman’s post? » GOOS Mailinglist, 2011. https://groups.google.com/d/topic/growing-object-oriented-software/dOmOIafFDcI/discussion